通信保障方案制訂通信保障是日常優(yōu)化中的重要組成保證部分，通信保障主要包括重要節(jié)假日以及重大活動(dòng)的通信保障。對(duì)于重大節(jié)假日以及重大活動(dòng)的保障涉及到應(yīng)急保障手段的制定執(zhí)行、現(xiàn)場(chǎng)突發(fā)情況的處理。通信保障方案的制定將直接關(guān)系網(wǎng)絡(luò)指標(biāo)以及現(xiàn)場(chǎng)用戶的感知，所以對(duì)通信保障方案進(jìn)行科學(xué)的預(yù)估，現(xiàn)場(chǎng)要準(zhǔn)備嚴(yán)格執(zhí)行并及時(shí)監(jiān)控應(yīng)對(duì)突發(fā)并在活動(dòng)結(jié)束后進(jìn)行網(wǎng)絡(luò)恢復(fù)。實(shí)施方案通信保障流程其中質(zhì)量把控點(diǎn)主要有三個(gè)，分別為在負(fù)荷分析的準(zhǔn)確性，保障方案的合理性，應(yīng)急保障處理的及時(shí)性。保障測(cè)試與保障方案通信保障參數(shù)和設(shè)備故障檢查大型集會(huì)及重大節(jié)假日前的參數(shù)檢查指導(dǎo)針對(duì)2、3、4G網(wǎng)絡(luò)的需求制定相應(yīng)的保障方案；內(nèi)容主要包括：1、資源調(diào)整核查；2、參數(shù)核查（半速率、接入、切換、234G互操作參數(shù)等）；3、鄰區(qū)核查與調(diào)整（包括網(wǎng)內(nèi)與網(wǎng)間）。大型集會(huì)及重大節(jié)假日前的設(shè)備檢查指導(dǎo)eNodeB設(shè)備狀態(tài)檢查在大型集會(huì)及重大節(jié)假日前，在eNodeB側(cè)需要重點(diǎn)檢查以下設(shè)備狀態(tài)：1、系統(tǒng)模塊狀態(tài)檢查；2、網(wǎng)管通道狀態(tài)檢查；3、接口狀態(tài)檢查；4、小區(qū)狀態(tài)檢查；5、風(fēng)扇的運(yùn)行情況檢查；6、GPS天線檢查；7、單板狀態(tài)檢查表；8、天饋線檢查；9、系統(tǒng)時(shí)鐘檢查。eNodeB設(shè)備告警檢查在大型集會(huì)及重大節(jié)假日前，在eNodeB側(cè)需要重點(diǎn)檢查以下設(shè)備告警，并根據(jù)告警處理步驟及時(shí)進(jìn)行處理：1、工作電源告警；2、風(fēng)扇運(yùn)行告警；3、GPS天線告警；4、單板狀態(tài)告警；5、天饋線告警；6、功放告警；7、RRU駐波比告警。網(wǎng)絡(luò)負(fù)荷分析1、資源容量評(píng)估識(shí)別當(dāng)前網(wǎng)絡(luò)大話務(wù)的容量風(fēng)險(xiǎn)，為網(wǎng)絡(luò)優(yōu)化調(diào)整提供輸入。所有風(fēng)險(xiǎn)都要基于容量評(píng)估的結(jié)論，必須重視。2、話務(wù)預(yù)測(cè)話務(wù)預(yù)測(cè)為后續(xù)的容量風(fēng)險(xiǎn)評(píng)估提供輸入，是關(guān)鍵環(huán)節(jié)之一。LTE系統(tǒng)資源（包括單板CPU和空口資源）的開(kāi)銷跟在線用戶數(shù)呈正比關(guān)系，因此大話務(wù)場(chǎng)景下資源容量的評(píng)估可基于用戶數(shù)完成，該文檔中話務(wù)預(yù)測(cè)特指用戶數(shù)（L.Traffic.User.Avg）的預(yù)測(cè)。首先預(yù)估整個(gè)保障區(qū)域平均在線用戶數(shù)規(guī)模，然后預(yù)測(cè)保障區(qū)域中每小區(qū)平均在線用戶數(shù)規(guī)模，最后根據(jù)小區(qū)和單板的配置關(guān)系累加得到每基帶板、每主控板的平均在線用戶數(shù)。（1）保障區(qū)域總體話務(wù)預(yù)測(cè)總體話務(wù)預(yù)測(cè)分為基于歷史數(shù)據(jù)的話務(wù)預(yù)測(cè)和無(wú)歷史數(shù)據(jù)的話務(wù)預(yù)測(cè)。建議首先采取前者來(lái)獲得更為準(zhǔn)確的預(yù)測(cè)結(jié)果。（2）小區(qū)話務(wù)預(yù)測(cè)小區(qū)話務(wù)預(yù)測(cè)通常有三種方法：基于歷史話務(wù)分布；基于預(yù)估人群集中區(qū)域；基于人群均分的原則預(yù)估各小區(qū)話務(wù)。從準(zhǔn)確性來(lái)講，方法1）到方法3）依次降低，但實(shí)施難度也依次降低。3、分析結(jié)果網(wǎng)絡(luò)健康檢查通過(guò)維護(hù)SOP巡檢，排除保障站點(diǎn)可能存在的設(shè)備狀態(tài)異常和KPI異常。軟件中心->版本軟件->無(wú)線->無(wú)線網(wǎng)管系統(tǒng)(868)->MAINEX(207)要求檢出的問(wèn)題要全部清理。容量風(fēng)險(xiǎn)評(píng)估基于話務(wù)預(yù)測(cè)章節(jié)預(yù)測(cè)出的小區(qū)、單板（基帶、主控）的平均在線用戶數(shù)，結(jié)合類似事件或當(dāng)前網(wǎng)絡(luò)的話務(wù)模型，評(píng)估當(dāng)前的硬件配置（主控板、基帶板、小區(qū)數(shù)量）和軟件資源（License用戶數(shù)容量）是否能承載預(yù)期話務(wù)。若不能承載，需給出明確的擴(kuò)容建議。容量風(fēng)險(xiǎn)評(píng)估邏輯流程如下：（1）硬件容量評(píng)估硬件容量評(píng)估是基于現(xiàn)網(wǎng)數(shù)據(jù)，預(yù)估主控板或基帶板過(guò)載時(shí)的用戶數(shù)門(mén)限。理論分析和經(jīng)驗(yàn)數(shù)據(jù)都表明，單板CPU負(fù)荷隨在線用戶數(shù)增加呈現(xiàn)線性增長(zhǎng)的趨勢(shì)，因此基于現(xiàn)網(wǎng)數(shù)據(jù)得出的線性增長(zhǎng)規(guī)律可以用來(lái)預(yù)測(cè)單板風(fēng)險(xiǎn)。數(shù)據(jù)的選擇原則為：若該區(qū)域最近3個(gè)月內(nèi)有高話務(wù)站點(diǎn)單基帶板平均在線用戶數(shù)超過(guò)100，則選用3~5個(gè)此類站點(diǎn)數(shù)據(jù)；若不滿足條件1），則選擇其它區(qū)域類似場(chǎng)景（如都是足球比賽）中單基帶板平均在線用戶數(shù)超過(guò)100的站點(diǎn)數(shù)據(jù)；若條件1）、2）都不滿足，則選擇全網(wǎng)最高話務(wù)3~5個(gè)站點(diǎn)數(shù)據(jù)。另外，為獲取更多數(shù)據(jù)樣本點(diǎn)以使得統(tǒng)計(jì)規(guī)律更為準(zhǔn)確，建議使用15分鐘粒度的話統(tǒng)數(shù)據(jù)。（2）CPU利用率當(dāng)CPU峰值利用率達(dá)到90%時(shí)將觸發(fā)嚴(yán)重流控導(dǎo)致KPI受損，因此容量調(diào)整的目的是避免CPU峰值利用率超過(guò)90%。然后按照上面計(jì)算得到的峰均比計(jì)算得到90%峰值利用率對(duì)應(yīng)的CPU平均利用率，即為過(guò)載門(mén)限。例如統(tǒng)計(jì)得到峰均比為1.5，則過(guò)載門(mén)限即為60%（=90%/1.5）。（3）License容量評(píng)估License在線用戶數(shù)受限將導(dǎo)致ERAB建立失敗。接入失敗的用戶業(yè)務(wù)需求得不到滿足必然反復(fù)重試，會(huì)增加大量接入信令，從而增加CPU和空口資源的開(kāi)銷。該風(fēng)險(xiǎn)一定要避免。4、負(fù)荷優(yōu)化方案擴(kuò)容建議主控板的擴(kuò)容方案有：換用UMPT、雙主控、站點(diǎn)分裂。擴(kuò)容演進(jìn)原則如下：如果評(píng)估主控板需要擴(kuò)容，則根據(jù)當(dāng)前配置情況選擇后一種演進(jìn)方案。例如當(dāng)前是LMPT，則建議換用單UMPT。建議在保障期間license在線用戶數(shù)申請(qǐng)最大值10800。引導(dǎo)客戶首先是購(gòu)買(mǎi)保障license，如果不行，在應(yīng)急場(chǎng)景下使用臨時(shí)license。注：License在線用戶數(shù)是指如下控制項(xiàng)：編號(hào)名稱中文LLT1ACTU01RRC連接用戶數(shù)（每RRC連接用戶數(shù)）英文LLT1ACTU01RRCConnectedUser(perRRCConnectedUser)保障參數(shù)策略接入?yún)?shù)優(yōu)化由于活動(dòng)保障的小區(qū)可能會(huì)突發(fā)高話務(wù)量、極端情況下還需要考慮會(huì)產(chǎn)生信令浪涌問(wèn)題。都可能導(dǎo)致系統(tǒng)負(fù)荷瞬間極具增大，帶來(lái)系統(tǒng)安全隱患。因而需要修改一些繼而參數(shù)，以降低高信令時(shí)的系統(tǒng)負(fù)荷。算法參數(shù)分類參數(shù)算法名稱作用建議設(shè)置值實(shí)施時(shí)間和范圍建議實(shí)施范圍信令接入及承載優(yōu)化T300提高T300的時(shí)間，可以降低一定時(shí)間內(nèi)RRC建立嘗試次數(shù)1.5短時(shí)熱點(diǎn)保障擁塞風(fēng)險(xiǎn)小區(qū)T302提高T302的時(shí)間，可以降低一定時(shí)間內(nèi)RRC建立嘗試次數(shù)16短時(shí)熱點(diǎn)保障存在擁塞小區(qū)CFI設(shè)置CFI固定設(shè)置為3，保證PDCCH信道資源3短時(shí)熱點(diǎn)保障存在擁塞小區(qū)PUCCH資源自適應(yīng)PUCCH資源自適應(yīng)開(kāi)關(guān)打開(kāi)，保證PUCCH信道資源OFF保持關(guān)閉狀態(tài)不變保障相關(guān)小區(qū)UE非激活定時(shí)器根據(jù)RRC建立次數(shù)受限還是用戶數(shù)受限做相應(yīng)的提高和降低（提高可以減少RRC建立次數(shù)，降低可以減少一定時(shí)段的在線用戶數(shù)）10短時(shí)熱點(diǎn)保障保障相關(guān)小區(qū)acbarringfactor通過(guò)減小該參數(shù)，可以減少一定時(shí)間內(nèi)的RRC建立嘗試次數(shù)0.95（0.7）短時(shí)熱點(diǎn)保障存在擁塞小區(qū)小區(qū)接納控制算法小區(qū)接納控制算法達(dá)到接納控制門(mén)限禁止用戶接入常開(kāi)保障相關(guān)小區(qū)（1）PUCCH資源自適應(yīng)，即根據(jù)用戶數(shù)的多少，動(dòng)態(tài)分配PUCCH的PRB資源，用戶數(shù)越多，PUCCH的PRB資源占用也就越多，我的建議是關(guān)閉PUCCH資源自適應(yīng)功能，理由如下：用戶數(shù)多，需要的PUCCH的PRB資源也多，因此沒(méi)有必要配置動(dòng)態(tài)PUCCH資源，以減輕系統(tǒng)的處理負(fù)荷；同樣的道理，用戶數(shù)多的情況下，需要的PDCCH資源也多，因此我們將CFI固定為3，也是出于相同的考慮；根據(jù)規(guī)范定義，某個(gè)UE的PUCCH所采用的PRB資源是由該UE的PDCCH的CCE首位置決定的。CFI的大小決定了CCE的多少，從而進(jìn)一步?jīng)Q定了PUCCH所需的最大PRB數(shù)量，現(xiàn)在CFI固定為3，PUCCH所需的PRB數(shù)量也固定下來(lái)了，因此也沒(méi)必要配置動(dòng)態(tài)PUCCH資源。（2）小區(qū)接納控制算法：當(dāng)小區(qū)達(dá)到最大用戶數(shù)后，若該小區(qū)下還有其他未接入的UE，這些UE還會(huì)發(fā)起RRCConnectionRequest，這樣的RRC建立肯定會(huì)被拒絕，現(xiàn)在采取的應(yīng)對(duì)方法是：a）增加T302，以增加UE重發(fā)RRCConnectionRequest的時(shí)延，從而減少RRCconnectionRequest消息的個(gè)數(shù)；b）開(kāi)啟AccessBarring功能，從而減少RRCconnectionRequest消息的個(gè)數(shù)。除非開(kāi)啟負(fù)載均衡功能，否則系統(tǒng)側(cè)沒(méi)有專門(mén)的接納控制算法。話務(wù)均衡保障方案不變化小區(qū)功率，通過(guò)重選和切換參數(shù)實(shí)現(xiàn)負(fù)荷向相鄰小區(qū)分流。高負(fù)荷小區(qū)只在鄰小區(qū)低于其負(fù)荷門(mén)限時(shí)才可分流。負(fù)荷均衡算法調(diào)整:應(yīng)用場(chǎng)景：F+D共站址小區(qū)間；F+D共覆蓋熱點(diǎn)區(qū)域；開(kāi)啟X2切換非共址小區(qū)。負(fù)荷均衡是用來(lái)平衡小區(qū)間、頻率間和無(wú)線接入技術(shù)之間的負(fù)荷，可以平衡整個(gè)系統(tǒng)的性能，提高系統(tǒng)的穩(wěn)定性。功能是根據(jù)服務(wù)小區(qū)和其鄰區(qū)負(fù)荷狀態(tài)或者用戶數(shù)情況合理部署小區(qū)運(yùn)行流量，有效地使用系統(tǒng)資源，以提高系統(tǒng)的容量和提高系統(tǒng)的穩(wěn)定性。目前中興機(jī)型雙載波同覆蓋的負(fù)載均衡是以PRB利用率為條件觸發(fā)，當(dāng)一個(gè)小區(qū)的負(fù)荷PRB利用率達(dá)到70%時(shí)，且鄰區(qū)PRB利用率低于65%，負(fù)荷均衡功能將被啟動(dòng)。華為機(jī)型雙載波同覆蓋的負(fù)載均衡是以用戶數(shù)為觸發(fā)條件，當(dāng)一個(gè)小區(qū)的用戶數(shù)達(dá)到40個(gè)，且鄰區(qū)用戶數(shù)低于20個(gè)，負(fù)荷均衡功能將被啟動(dòng)（門(mén)限可調(diào)整）。華為機(jī)型負(fù)荷均衡參數(shù)：華為參數(shù)華為參數(shù)名稱MML分類推薦值異頻MLB開(kāi)關(guān)InterFreqMlbSwitchMODCELLALGOSWITCHMLBInterFreqMlbSwitch-1負(fù)載均衡觸發(fā)模式MLBTRIGGERMODEMODCELLMLBMLBUE_NUMBER_ONLY異頻負(fù)載均衡用戶數(shù)門(mén)限INTERFREQMLBUENUMTHDMODCELLMLBMLB40負(fù)載均衡用戶數(shù)偏置MLBUENUMOFFSETMODCELLMLBMLB20基于負(fù)載的異頻RSRP觸發(fā)門(mén)限(毫瓦分貝)INTERFREQLOADBASEDHOA4THDRSRPMODINTERFREQHOGROUP異頻切換-99基于覆蓋的異頻RSRP觸發(fā)門(mén)限(毫瓦分貝)INTERFRQQHOA4THDRSCPMODINTERFREQHOGROUP異頻切換-95中興機(jī)型負(fù)荷均衡參數(shù)：MO對(duì)象名短名參數(shù)名稱（中文）參數(shù)涵義取值范圍調(diào)整前調(diào)整后負(fù)荷均衡參數(shù)配置ucLBSwch負(fù)荷均衡算法開(kāi)關(guān)小區(qū)負(fù)荷均衡算法開(kāi)關(guān)，它決定了本eNB是否使用負(fù)荷均衡功能，以及選擇采用盲切換的方式還是采用基于事件測(cè)量的切換方式。0:算法關(guān)閉(Close)Close[0]21:采用盲切換的方式2:采用基于事件測(cè)量的切換方式負(fù)荷均衡參數(shù)配置ucUlPRBLBExeThrdZ上行ZTE無(wú)線負(fù)荷均衡執(zhí)行門(mén)限用于執(zhí)行小區(qū)上行方向ZTE無(wú)線負(fù)荷均衡功能。當(dāng)LTE服務(wù)小區(qū)在統(tǒng)計(jì)窗長(zhǎng)時(shí)間內(nèi)上行PRB的平均使用率大于這個(gè)門(mén)限值時(shí)，本小區(qū)執(zhí)行上行ZTE負(fù)荷均衡。[0,100]unitpercent6530負(fù)荷均衡參數(shù)配置ucDlPRBLBExeThrdZ下行ZTE無(wú)線負(fù)荷均衡執(zhí)行門(mén)限用于執(zhí)行小區(qū)下行方向ZTE無(wú)線負(fù)荷均衡功能。當(dāng)LTE服務(wù)小區(qū)在統(tǒng)計(jì)窗長(zhǎng)時(shí)間內(nèi)下行PRB的平均使用率大于這個(gè)門(mén)限值時(shí)，本小區(qū)執(zhí)行下行ZTE負(fù)荷均衡。[0,100]unitpercent6530負(fù)荷均衡參數(shù)配置ucUlIntraNeighborLoadThrd上行Intra-LTE鄰小區(qū)過(guò)負(fù)荷門(mén)限用于判斷Intra-LTE相鄰小區(qū)的上行負(fù)荷水平。當(dāng)Intra-LTE相鄰小區(qū)上行PRB使用率的值高于這個(gè)門(mén)限值時(shí)，則不將該小區(qū)作為Intra-LTE負(fù)荷均衡的候選目標(biāo)小區(qū)。[0,100]unitpercent6025負(fù)荷均衡參數(shù)配置ucDlIntraNeighborLoadThrd下行Intra-LTE鄰小區(qū)過(guò)負(fù)荷門(mén)限用于判斷Intra-LTE相鄰小區(qū)的下行負(fù)荷水平。當(dāng)Intra-LTE相鄰小區(qū)下行PRB使用率的值高于這個(gè)門(mén)限值時(shí)，則不將該小區(qū)作為Intra-LTE負(fù)荷均衡的候選目標(biāo)小區(qū)。[0,100]unitpercent6025事件判決的RSRP門(mén)限(dBm)thresholdOfRSRP事件判決的RSRP門(mén)限(dBm)測(cè)量時(shí)服務(wù)小區(qū)事件判決的RSRP絕對(duì)門(mén)限,用于A1，A2，A4，A5事件的判決long:[-140~-43];default:-75-90-90保障測(cè)試保障前測(cè)試保障測(cè)試主要是對(duì)各類活動(dòng)現(xiàn)場(chǎng)進(jìn)行測(cè)試，保障各類活動(dòng)能夠正常度過(guò)。保障測(cè)試由前臺(tái)測(cè)試組對(duì)現(xiàn)場(chǎng)進(jìn)行全方位DT和CQT摸底測(cè)試以便了解活動(dòng)現(xiàn)場(chǎng)的2、3、4G網(wǎng)絡(luò)覆蓋情況和存在的問(wèn)題點(diǎn)。在確認(rèn)活動(dòng)現(xiàn)場(chǎng)存在的問(wèn)題點(diǎn)后制定相應(yīng)的解決方案并跟蹤執(zhí)行。調(diào)整后進(jìn)行復(fù)測(cè)試驗(yàn)證調(diào)整效果。對(duì)活動(dòng)現(xiàn)場(chǎng)進(jìn)行測(cè)試，反饋活動(dòng)現(xiàn)場(chǎng)是否存在問(wèn)題點(diǎn)（如質(zhì)差、小區(qū)過(guò)覆蓋、弱覆蓋等情況），若存在能現(xiàn)場(chǎng)解決的現(xiàn)場(chǎng)解決，不能現(xiàn)場(chǎng)解決的納入問(wèn)題跟蹤表跟蹤處理直至解決。活動(dòng)時(shí)的現(xiàn)場(chǎng)保障（1）前臺(tái)測(cè)試人員提前2小時(shí)抵達(dá)活動(dòng)現(xiàn)場(chǎng)并對(duì)現(xiàn)場(chǎng)進(jìn)行各項(xiàng)測(cè)試，并向保障負(fù)責(zé)人反饋測(cè)試情況；有應(yīng)急通信車的需要在應(yīng)急通信車開(kāi)啟后進(jìn)行測(cè)試；（2）后臺(tái)人員提前觀察當(dāng)天要舉辦活動(dòng)的占用小區(qū)各項(xiàng)指標(biāo)、告警，并向保障負(fù)責(zé)人反饋監(jiān)控情況；活動(dòng)開(kāi)始后對(duì)各小區(qū)進(jìn)行實(shí)時(shí)監(jiān)控。性能監(jiān)控開(kāi)展性能指標(biāo)、CPU負(fù)荷、用戶量以及基站狀態(tài)監(jiān)控工作，針對(duì)網(wǎng)絡(luò)負(fù)荷、硬件故障等分場(chǎng)景進(jìn)行應(yīng)急保障工作。性能指標(biāo)監(jiān)控：對(duì)10項(xiàng)性能指標(biāo)進(jìn)行監(jiān)控，異常告警門(mén)限如下：E-RAB擁塞次數(shù)RRC擁塞次數(shù)RRC建立成功率z(%)E-RAB建立成功率z(%)E-RAB掉線率z(%)無(wú)線接通率z(%)無(wú)線掉線率z(%)切換成功率z(%)10010090%90%1%90%1%90%CPU負(fù)荷監(jiān)控：對(duì)基帶板、主控板CPU負(fù)荷進(jìn)行時(shí)時(shí)監(jiān)控，異常告警門(mén)限如下：主控板總CAPA基帶板總CAPS60%60%用戶數(shù)量監(jiān)控：對(duì)小區(qū)平均激活用戶數(shù)、最大激活用戶數(shù)進(jìn)行監(jiān)控，用戶量告警門(mén)限如下：平均激活用戶數(shù)最大激活用戶數(shù)150200小區(qū)狀態(tài)監(jiān)控：對(duì)現(xiàn)網(wǎng)基站狀態(tài)進(jìn)行監(jiān)控，對(duì)于出現(xiàn)告警站點(diǎn)，及時(shí)告知維護(hù)人員進(jìn)行處理，保障基站穩(wěn)定運(yùn)行。應(yīng)急預(yù)案在值守開(kāi)始前要預(yù)先制定應(yīng)急預(yù)案，并拉通相關(guān)資源進(jìn)行演練，確保問(wèn)題能夠有序高效的處理。應(yīng)急預(yù)案主要分為以下場(chǎng)景：告警應(yīng)急處理活動(dòng)過(guò)程中，需要關(guān)注的告警如下：類型告警名稱告警ID觸發(fā)原因處理建議CPU過(guò)載單板過(guò)載告警ALM-26202當(dāng)單板處理芯片占用率過(guò)高時(shí)，產(chǎn)生此告警。1）如果確定是業(yè)務(wù)量導(dǎo)致的（比如用戶數(shù)接近規(guī)格），進(jìn)行處理；2）如果不是，建議重啟單板；3）如果仍不能恢復(fù)，需要更換單板。硬件故障單板硬件故障告警ALM-26200單板硬件故障時(shí)，產(chǎn)生此告警。建議首先重啟單板；如果仍不能恢復(fù)，需要考慮更換單板。License容量不足系統(tǒng)超出License容量限制告警ALM-26812當(dāng)網(wǎng)元系統(tǒng)業(yè)務(wù)量持續(xù)超出License容量限制（可設(shè)置）時(shí)，產(chǎn)生此告警。當(dāng)網(wǎng)元系統(tǒng)業(yè)務(wù)量持續(xù)低于License容量限制的90%時(shí)，恢復(fù)該告警。與客戶溝通，啟用固定期限/緊急License。傳輸擁塞SCTP鏈路擁塞告警ALM-25889當(dāng)SCTP發(fā)送緩存被大量需要重傳的數(shù)據(jù)占用，占用比例達(dá)到整個(gè)發(fā)送緩沖區(qū)的擁塞產(chǎn)生門(mén)限時(shí)，產(chǎn)生此警。如是用戶數(shù)引起，需要進(jìn)行用戶數(shù)制；嘗試重置SCTP鏈路；重啟單板。小區(qū)狀態(tài)小區(qū)不可用告警ALM-29240當(dāng)基站檢測(cè)到小區(qū)不能提供業(yè)務(wù)時(shí)，產(chǎn)生此告警。重啟基站。小區(qū)無(wú)話務(wù)量告警ALM-29242當(dāng)eNodeB檢測(cè)到小區(qū)在設(shè)置時(shí)間內(nèi)無(wú)用戶接入時(shí)，產(chǎn)生此告警。重啟基站。小區(qū)服務(wù)能力下降告警ALM-29243當(dāng)基站射頻資源或基帶資源不能滿足當(dāng)前小區(qū)的配置規(guī)格時(shí)，產(chǎn)生此告警。依據(jù)告警幫助進(jìn)行處理。KPI觀測(cè)監(jiān)控上文中給出的KPI。CPU觀測(cè)按照上文中給出的方法監(jiān)控CPU負(fù)荷。問(wèn)題處理首先按照事先準(zhǔn)備的應(yīng)急預(yù)案處理恢復(fù)。若不能取得理想效果，聯(lián)系電話值班人員進(jìn)行問(wèn)題分析處理。KPI通報(bào)值守期間需定期發(fā)送KPI監(jiān)控?cái)?shù)據(jù)。以便于相關(guān)保障值守人員及時(shí)了解詳細(xì)情況，可提升問(wèn)題響應(yīng)速度。該環(huán)節(jié)務(wù)必執(zhí)行到位。現(xiàn)場(chǎng)人力情況，可考慮每30或60分鐘發(fā)送一次。數(shù)據(jù)收集值守期間及時(shí)備份日志數(shù)據(jù)非常重要，因?yàn)楦咴拕?wù)期間日志數(shù)據(jù)量大，保存時(shí)間短。若不及時(shí)備份，一旦事后出現(xiàn)問(wèn)題，或有其它類似的數(shù)據(jù)分析需求，很可能面臨無(wú)日志可參考的困境。為避免該問(wèn)題，需要在每天保障結(jié)束后導(dǎo)出保障站點(diǎn)的主控一鍵式日志。主控一鍵式日志的導(dǎo)出對(duì)主控CPU占有率有影響，因此必須在話務(wù)回落后執(zhí)行。建議等到主控CPU峰值占有率低于50%后。主控一鍵式日志文件較大，如果保障區(qū)域站點(diǎn)眾多，可只備份話務(wù)最高的TOP3站點(diǎn)。另外，保障站點(diǎn)的配置文件也一并提取。RRC建立成功率急劇惡化應(yīng)急處理入口條件單次15分鐘話統(tǒng)發(fā)現(xiàn)RRC建立成功率急劇惡化（惡化程度已經(jīng)超過(guò)客戶預(yù)期。如果客戶沒(méi)有明確預(yù)期，建議門(mén)限為90%）。RRC建立成功率應(yīng)急措施總體處理流程如下：各環(huán)節(jié)判斷方法及詳細(xì)處理建議參考如下?，F(xiàn)象原因確認(rèn)方法處理建議RRC建立成功率惡化無(wú)線資源受限L.RRC.SetupFail.ResFail有大量統(tǒng)計(jì)判斷是否用戶數(shù)規(guī)格受限。用戶數(shù)超過(guò)小區(qū)/單板規(guī)格L.RRC.SetupFail.ResFail.UserSpec統(tǒng)計(jì)值占L.RRC.SetupFail.ResFail的大部分。1.修改T302定時(shí)器到16s。2.考慮收縮覆蓋。將RS功率降低3~6DB以收縮覆蓋。但該措施有可能對(duì)同頻鄰區(qū)，及同覆蓋的異頻/異系統(tǒng)鄰區(qū)帶來(lái)短時(shí)話務(wù)沖擊，并可能出現(xiàn)覆蓋盲區(qū)從而部分用戶完全失去服務(wù)，具體影響可聯(lián)系當(dāng)?shù)豏F團(tuán)隊(duì)評(píng)估。3.啟用ACBAR。該措施不會(huì)對(duì)鄰區(qū)產(chǎn)生話務(wù)沖擊，但會(huì)增加本小區(qū)全部用戶的接入時(shí)延。執(zhí)行如下兩條命令，如果執(zhí)行下面的命令后用戶數(shù)仍然超，可以把第二條命令中黃色標(biāo)識(shí)的參數(shù)接入概率進(jìn)一步降低，延遲時(shí)間進(jìn)一步拉長(zhǎng)。用戶數(shù)未超過(guò)規(guī)格，或無(wú)法判斷。L.RRC.SetupFail.ResFail.UserSpec統(tǒng)計(jì)值只占L.RRC.SetupFail.ResFail的小部分。檢查并確認(rèn)如下資源自適應(yīng)開(kāi)關(guān)已全部打開(kāi)：SRI資源自動(dòng)調(diào)整；PUCCH資源自動(dòng)調(diào)整；CQI周期自動(dòng)調(diào)整；SRS周期自適應(yīng)調(diào)整；SRS子幀配置重配開(kāi)關(guān)調(diào)整；恢復(fù)SRS子幀配置（SrsSubframeCfg）為默認(rèn)配置。MME過(guò)載L.RRC.SetupFail.Rej.MMEOverload有大量統(tǒng)計(jì)。降低接入次數(shù)。有大量Msg3因流控而被拒絕或丟棄。L.RRC.ConnReq.Msg.disc.FlowCtrl或L.RRC.SetupFail.Rej.FlowCtrl有大量統(tǒng)計(jì)；判斷是否CPU過(guò)載。CPU負(fù)荷較高導(dǎo)致Msg3被丟棄或拒絕跟蹤或話統(tǒng)查詢到主控或基帶板CPU最大占有率超過(guò)80%；或者基站上報(bào)單板過(guò)載告警；1.如果是基帶板過(guò)載，直接關(guān)閉DRX；如果是主控板過(guò)載，將DRX進(jìn)入退出門(mén)限配置為1000，或直接關(guān)閉DRX。2.降低接入次數(shù)。干擾抬升，空口惡化.以下兩個(gè)條件同時(shí)滿足：L.RRC.SetupFail.NoReply有大量統(tǒng)計(jì)；L.UL.Interference.Avg抬升超過(guò)20DB；實(shí)施干擾抑制措施，包括：開(kāi)啟上行干擾隨機(jī)化；關(guān)閉同頻鄰區(qū)的下行頻選；限制PUSCHRSRP上門(mén)限。若不能達(dá)到預(yù)期效果，考慮收縮覆蓋，將RS功率降低3~6DB以收縮覆蓋。具體影響及MML請(qǐng)參考該表1.1節(jié)措施。ERAB建立成功率急劇惡化應(yīng)急處理入口條件單次15分鐘話統(tǒng)發(fā)現(xiàn)ERAB建立成功率急劇惡化（惡化程度已經(jīng)超過(guò)客戶預(yù)期。如果客戶沒(méi)有明確預(yù)期，建議門(mén)限為90%）。ERAB建立成功率惡化應(yīng)急措施總體處理流程如下：各環(huán)節(jié)判斷方法及詳細(xì)處理建議參考如下。原因確認(rèn)方法處理建議1.傳輸原因?qū)е翬RAB建立失敗L.E-RAB.FailEst.TNL有大量統(tǒng)計(jì)；判斷是否傳輸擁塞。1.1傳輸擁塞導(dǎo)致ERAB建立失敗有SCTP鏈路擁塞告警；按照如下方法限制接入次數(shù)，緩解SCTP擁塞：1.修改T302定時(shí)器到16s；2、考慮收縮覆蓋。將RS功率降低3~6DB以收縮覆蓋；3.啟用ACBAR。該措施會(huì)增加本小區(qū)全部用戶的接入時(shí)延。執(zhí)行如下兩條命令，如果執(zhí)行下面的命令后用戶數(shù)仍然超，可以把第二條命令中黃色標(biāo)識(shí)的參數(shù)接入概率進(jìn)一步降低，延遲時(shí)間進(jìn)一步拉長(zhǎng)。2.MME原因?qū)е翬RAB建立失敗L.E-RAB.FailEst.MME有大量統(tǒng)計(jì)判斷是否干擾太大。2.1干擾導(dǎo)致空口消息交互延遲，MME定時(shí)器超時(shí)先釋放L.UL.Interference.Avg抬升超過(guò)20DB；實(shí)施干擾抑制措施，包括：上行干擾隨機(jī)化；關(guān)閉同頻鄰區(qū)的下行頻選；限制PUSCHRSRP上門(mén)限。若不能達(dá)到預(yù)期效果，考慮收縮覆蓋，將RS功率降低3~6DB以收縮覆蓋。3.無(wú)線側(cè)信令交互失敗導(dǎo)致ERAB建立失敗L.E-RAB.FailEst.NoReply或L.E-RAB.FailEst.SRBReset有大量統(tǒng)計(jì)判斷是否干擾太大。3.1干擾導(dǎo)致空口信令交互失敗判斷是否干擾太大。參考該表2.1節(jié)措施處理。4.無(wú)線資源不足導(dǎo)致ERAB建立失敗L.E-RAB.FailEst.NoRadioRes有大量打點(diǎn)按照該表4.1節(jié)繼續(xù)判斷是否用戶數(shù)或流量license受限4.1用戶數(shù)或流量license受限基站上報(bào)license容量超限告警（ALM-26812）或基站所有小區(qū)最大在線用戶數(shù)（L.Traffic.User.Max）之和超過(guò)License用戶數(shù)規(guī)格的90%；先考慮加載臨時(shí)License；或啟用緊急狀態(tài)License；若上述措施無(wú)法執(zhí)行，參考1.1的措施限制用戶接入。4.2用戶數(shù)或流量license未受限以下條件都不滿足。基站上報(bào)license容量超限告警（ALM-26812）；基站所有小區(qū)最大在線用戶數(shù)（L.Traffic.User.Max）之和超過(guò)License用戶數(shù)規(guī)格的90%；