淄博移動LTE網(wǎng)絡(luò)春節(jié)保障方案

2019-11-華為2019-11-華為保密信息,未經(jīng)授權(quán)禁止擴PAGE1頁,NUMPAGES1511為避免在春節(jié)期間人口聚集、話務(wù)量激增對基站及EPC造成巨大沖擊（如：接入成功率、掉話率、用戶體驗速率等KPI下降），擬定該春節(jié)保障方案，應(yīng)對話務(wù)量激增場景，保障網(wǎng)絡(luò)正常運行。具體節(jié)日保障措施、流程22資源容量評估、網(wǎng)絡(luò)健康檢查、網(wǎng)絡(luò)調(diào)整、制定應(yīng)急預案，以及保障準備。大話務(wù)場景下的風險，具體來講主要有兩類：一是隨用戶數(shù)增加，信令數(shù)量顯著增加，可能出現(xiàn)單板CPU過載并觸發(fā)流控，從而導致KPI節(jié)前準備階段通過擴容及RF優(yōu)化等措施可有效降低單板CPU過載和同頻干擾風險，需重點關(guān)注資資源容量評識別當前網(wǎng)絡(luò)大話務(wù)的容量風險為網(wǎng)絡(luò)優(yōu)化調(diào)整提供輸入所有風險都要基于容量評估的結(jié)論必須重視話務(wù)預LTE包括單板CPU的戶數(shù)L.Traffic.User.Av）的預測。區(qū)和單板的配置關(guān)系累加得到每基帶板、每主控板的平均在線用戶數(shù)?？傮w話務(wù)預測分為基于歷史數(shù)據(jù)的話務(wù)預測和無歷史數(shù)據(jù)的話務(wù)預測預測結(jié)果。（2）（2） 基于預估人群集中區(qū)域基于人群均分的原則預估各小區(qū)話務(wù)從準確性來講，方法）到方法）如下附件：（3）（3）ll了預測的該基帶板的平均在線用戶數(shù)；ll將該基站所有小區(qū)預測的平均在線用戶數(shù)相加就得到了預測的該主控板均在線用戶數(shù)基于2.1.1License容量風險評估邏輯流程參考如下（1）（1）U風險。數(shù)據(jù)的選擇原則為若該區(qū)域最近3個月內(nèi)有高話務(wù)站點單基帶板平均在線用戶數(shù)超過100則選用3~5若不滿足條件1），則選擇其它區(qū)域類似場景（如都是足球比賽）100若條件1）、2）都不滿足，則選擇全網(wǎng)最高話務(wù)3~5個站點數(shù)據(jù)另外，為獲取更多數(shù)據(jù)樣本點以使得統(tǒng)計規(guī)律更為準確，建議使用15分鐘粒度的話統(tǒng)數(shù)據(jù)CPU利用CPU值利用率達到90%時將觸發(fā)嚴重流控導致KPI損因此容量調(diào)整的目的是避CPU值利用率超過90%。然后按照上面計算得到的峰均比計算得到90%峰值利用率對應(yīng)的CPU平均利用率，即為過載門限。例如統(tǒng)計得到峰均比為1.5，則過載門限即60%（=90%1.5）。擴容建主控板的擴容方案有：換用UMPT、雙主控、站點分裂。擴容演進原則如下如果評估主控板需要擴容，則根據(jù)當前配置情況選擇后一種演進方案。例如當前是LMP單UMP。LicensLicense在線用戶數(shù)受限將導ERAB建立失敗。接入失敗的用戶業(yè)務(wù)需求得不到滿足必然反復重試會增加大量接入信令，從而增加CPU和空口資源的開銷。該風險一定要避免。建議在保障期間license在線用戶數(shù)申請最大值10800Connected引導客戶首先是購買保障censcens。注：LcenseConnected編名中RRC連接用戶數(shù)（每RRC連接用戶數(shù)英 容容量受特性影響風險評某些特性可能導致LTE系統(tǒng)容量發(fā)生顯著變化在資源容量評估環(huán)節(jié)需特別加以注意現(xiàn)在已知的是SFN 通過維護SOP檢，排除保障站點可能存在的設(shè)備狀態(tài)異常和KPI常。軟件中心->版本軟件->無線->無線網(wǎng)管系統(tǒng)(868)>MAINEX(207)要求檢出的問題要全部清理。網(wǎng)網(wǎng)絡(luò)調(diào)整優(yōu)小區(qū)分裂等。此次淄博針對春節(jié)大話務(wù)情況對19公網(wǎng)D頻段小區(qū)和室分8個E頻段小區(qū)進行了擴容操作如下表所示基于話務(wù)預測結(jié)果和實際保障經(jīng)驗，如果預計單小區(qū)峰值在線用戶數(shù)將超過400，建議升級到大話務(wù)性能最優(yōu)的版本，目前淄博移動LTE絡(luò)已經(jīng)完成公網(wǎng)和高鐵的版本升級。公網(wǎng)升級至eRAN7.0SPC175，高鐵升級至eRAN8.0SPC120版本。ERAN7.0本開始，異頻MLB法逐漸成熟并開始在大話務(wù)保障中應(yīng)用。異頻MLB按照觸發(fā)方式，分為基于PRB利用率和基于用戶數(shù)兩種，圖示如下：PRB利用率的MLB效果不理想，因此推薦基于用戶數(shù)的ML。異頻MLB照執(zhí)行方式，分為連接MLB空閑態(tài)MLB種。圖示如下連接態(tài)MLB用于各種覆蓋場景但卻有切換信令開銷在高話務(wù)場景下對CPU空口資源開銷有一定影響。因此在適用空閑態(tài)MLB的覆蓋場景下優(yōu)先推薦空閑態(tài)MLB。大話務(wù)常見的覆蓋場景以及對應(yīng)的MLB推薦策略如下1.采用基于用戶數(shù)的空閑態(tài)MLB（負載均衡的某個目標頻點就一個小區(qū)（例如：Fre1<-->Freq2 互相均衡時，F(xiàn)re1和Fre2頻點小區(qū)都只有一個）； 同站部分共覆蓋區(qū)域(某個頻點覆蓋范圍較小且未形成連續(xù) 范圍小的載波蓋,如僅能覆蓋其它頻點的30%用戶及以下，如宏微異頻組網(wǎng)，微站 2.采用基于用戶數(shù)的空閑態(tài)MLB（要單向配置 負載均衡的某個目標頻點就一個小區(qū)（例如：Fre1-->Freq2 均衡時，F(xiàn)re2頻點小區(qū)只有一個）；異站負載均衡小區(qū)部分共覆蓋區(qū)域 MLB負載均衡的某個目標頻點有多個小區(qū)（例如：Fre1-- 即負載均衡的小區(qū)要互為均衡 不同頻點帶寬大小差異無要求 時候，通過連接態(tài)負載均衡，使得均衡到低 RF根據(jù)保障經(jīng)驗，影響LTE性能的首要因素是RF覆蓋質(zhì)量。良好的RF覆蓋能夠保證較高的上下行頻譜效率，基于歷史數(shù)據(jù)經(jīng)驗，同一個區(qū)域的兩次活動，當RF優(yōu)化充分時，話務(wù)高峰期鄰區(qū)間上行干擾可控制在10dB以內(nèi)；而在RF優(yōu)化不合理時，同等話務(wù)規(guī)模時鄰區(qū)間上行干擾超過20dB。由此帶來的下行用戶感知速率的差距超過20性能參數(shù)優(yōu)性能保障參數(shù)建議在擴容和版本升級后，活動開始前7實施，觀察實施后KPI否有異常。如果保障區(qū)域在活動開始前完全無話務(wù)，則建議在路測之前實施，以便利用路測KPI驗證是否有異常。參數(shù)調(diào)整checklist應(yīng)應(yīng)急預要分為以下場景：告警應(yīng)急處值守期間若出現(xiàn)告警，請按照如下原則進行處理首先按照告警幫助進行處理（重啟和換板措施在本步驟先不考慮若不能消除告警，求助產(chǎn)品維護保障值守人員RRC建立成功率急劇惡化應(yīng)急處入入口條單次90。應(yīng)急措總體處理流程如下RRCRRCYY11.1拉長T302NNNYY2MME絕YNNNYNY3有大量RejMsg3YY3.1CPU關(guān)閉DRXNN啟用AC4YYNN位法及詳細處理建議參考如下 原 確認方 處理建 1.立源受限惡L.RRC.SetupFail.ResFail有

按照該表1.1節(jié)繼續(xù)判斷是否用戶數(shù)規(guī)格受限用戶數(shù)超過小區(qū)/

對于ERAN7.0及之后版本il.UserSpecL.RRC.SetupFail.ResFail大部分1.2節(jié)。

修改 定時器到 16s： RRCCONNSTATETIMER:T302=16;2、考慮收縮覆蓋。將RS功率降低DB施有可能對同頻鄰區(qū)，及同覆蓋的異頻/異系統(tǒng)鄰區(qū)帶來短時話務(wù)可聯(lián)系當?shù)豏F團隊評估。MODPDSH:cX,.用戶數(shù)MME載有大量控而被拒或丟棄

對于ERAN7.0及之后版本il.UserSpec統(tǒng)計值只占L.RRC.SetupFail.ResFail小部分對于ERAN7.0及之后本：L.RRC.SetupFail.Rej.MMEOverload有大量統(tǒng)計。對于ERAN7.0之前版本法快速判斷，跳過該環(huán)節(jié) Ctrl有大量統(tǒng)計；

概率進一步降低，延遲時間進一步拉長 檢查并確認如下資源自適應(yīng)開關(guān)已全部打開SRIMODPUCCHMODLocalCellId=x,PucchAlgoSwitch=PucchSwitch-CQIMODSRSMOD 子幀配置重配開關(guān)調(diào)整：MODSRSCFG:SrsSubframeCfg=SC3參考該表1.1節(jié)“用戶數(shù)超過基站規(guī)格”處理，降低接入次數(shù)CPU

?M2000跟蹤或話統(tǒng)查詢到主控或基帶CPU最大占報單板過載告警

如果是基帶板過載，直接關(guān)閉DRX；如果是主控板過載，將MODDRX:DrxAlgSwitch=ON;//關(guān)閉 FddEnterDrxThd=1000,FddExitDrxThd=1000;//修改進退出門限參考該表1.1用戶數(shù)超過基站規(guī)格處理降低接入次數(shù)44.1?上行干擾 有大量統(tǒng)計 hIrcSwitch-1;注意，有l(wèi)icense控制，控制項為：LOFD-001094ControlChannel關(guān)閉同頻鄰區(qū)的下行頻選：MOD 限制PUSCHRSRP上門限（PuschRsrpHighThd）：MOD UlPcAlgoSwitch=PuschRsrpHighThdSwitch- ERAN7.02、RSERAB建立成功率急劇惡化應(yīng)急處入入口條單次90。應(yīng)急措總體處理流程如下ERAB建立失1失敗原ERAB建立失1失敗原因都YY1.1傳輸擁塞拉長T302定時NN聯(lián)系傳輸人員分N聯(lián)系核心網(wǎng)分Y2失敗原因都2.1干擾太大問題解決Y3失敗原因都NNYY3.1干擾太大 干擾優(yōu)NY收縮覆問題解決NY問題解決4失敗原因都 4.1用戶數(shù)或單YNLicense受限，啟用臨License或應(yīng)急NN啟用AC打開資源自適應(yīng)配開NY問題解決結(jié)返回日志定細處理建議參考如下 原 確認方 處理建AB1.傳輸原立因?qū)е翬RAB建立惡失敗1.1傳輸擁塞導致ERAB建立

L.E-RAB.FailEst.TNL有大量統(tǒng)計 按照該表1.1節(jié)繼續(xù)判斷是否傳輸擁塞T30216s：MODRRCCONNSTATETIMERT302=16;覆蓋。但該措施有可能對同頻鄰區(qū)，及同覆蓋的異/異系統(tǒng)鄰區(qū)帶來短時話務(wù)沖擊，并可能出現(xiàn)覆蓋區(qū)從而部分用戶完全失去服務(wù)，具體影響可聯(lián)系當RF團隊評估。MODPDSCHCFG:SCTP鏈路擁塞告警

但會增加本小區(qū)全部用戶的接入時延。執(zhí)行如下兩條命令，如果執(zhí)行下面的命令后用戶數(shù)仍然超，可以把第二條命令中黃色標識的參數(shù)接入概率進一步降低，延遲時間進一步拉長； 2019-11-華為2019-11-華為保密信息,未經(jīng)授權(quán)禁止擴PAGE10頁,NUMPAGES15MME因?qū)е翬RAB建立干擾導交互延遲MME

MODCELLACBAR:AcBarringInfoCfgInd=CFG, L.E-RAB.FailEst.MME有大量統(tǒng) 按照該表2.1節(jié)繼續(xù)判斷是否干擾太大實施干擾抑制措施，包括上行干擾隨機化： ：MODWITCH=PucchIrcSwitch-1;license控制，控制項為LOFD-001094關(guān)閉同頻鄰區(qū)的下行頻選： 側(cè)

L.UL.Interference.Avg抬升超過L.E-

UlPcAlgoSwitch=PuschRsrpHighThdSwitch-//ERAN7.0開始支持2.若不能達到預期效果，考慮收縮覆蓋，將RS頻鄰區(qū)，及同覆蓋的異頻/異系統(tǒng)鄰區(qū)帶來短時話沖擊，并可能出現(xiàn)覆蓋盲區(qū)從而部分用戶完全失去服務(wù)，具體影響可聯(lián)系當?shù)豏F團隊評估。 敗導致ERAB建立干擾導

L.E-RAB.FailEst.SRBReset有大量統(tǒng) 按照該表3.1節(jié)繼續(xù)判斷是否干擾太大 無線資ERAB建立

L.E-RAB.FailEst.NoRadioRes有大量打

按照該表4.1節(jié)繼續(xù)判斷是否用戶數(shù)或流量受用戶數(shù)或流量用戶數(shù)或流量

以下條件滿足任意一個即可license（ALM-L.E-有大量打點L.E-有大量打點（L.Traffic.User.Max）之和超過用戶數(shù)規(guī)格的以下條件都不滿足license（ALM-L.E-有大量打點L.E-有大量打點基站所有小區(qū)最大在線用戶數(shù)（L.Traffic.User.Max）之和超過License用戶數(shù)規(guī)格的90%；

1、先考慮加載臨時2、或啟用緊急狀態(tài)License：SETLICENSECTRL:FUNCTIONTYPE=eNodeB;（每個R版本只能用3次）；3上述措施無法執(zhí)行參考1.1的措施限制用戶檢查并確認如下資源自適應(yīng)開關(guān)已全部打開SRI資源自動調(diào)整：PUCCH資源自動調(diào)整方案：MOD SRS周期自適應(yīng)調(diào)整：MODSRS置：MODSRSCFG:SrsSubframeCfg=掉話率急劇惡化應(yīng)急處入入口條單次15分鐘話統(tǒng)發(fā)現(xiàn)掉話率急劇惡化（惡化程度已經(jīng)超過客戶預期。如果客戶沒有明確預期，建議門限應(yīng)急措總體處理流程如下各環(huán)節(jié)判斷方法及詳細處理建議參考如下 原 確認方 處理建話惡與GAP周

L.E-RAB.AbnormRel.Radio有大量統(tǒng)計存在GAP場景，如異頻切換、CA等

1;//eRAN6.0SPC270及之后版本支持。//eRAN7.0SPC160及之后版本支持2.升，空口?實施干擾抑制措施，包括上行干擾隨機化：量惡? WITCH=PucchIrcSwitch-1;//注意，license控制，控制項為LOFD-ControlChannel? L.UL.Interference.Avg抬升超過

UlPcAlgoSwitch=PuschRsrpHighThdSwitch-//ERAN7.0開始支持若不能達到預期效果，考慮收縮覆蓋，將功率降低DB/沖擊，并可能出現(xiàn)覆蓋盲區(qū)從而部分用戶完全失去服務(wù)，具體影響可聯(lián)系當?shù)豏F團隊評估。 備份數(shù)備份配置和采集日志均可使用M2000遠程操作和WebLmt近端操作，推薦使用M2000操作；（參數(shù)修改前KPI控模板制目前的KPI指標情況如下表所示目的：話務(wù)高峰來臨前現(xiàn)場應(yīng)該事先確認登記下面的15分鐘話統(tǒng)指標設(shè)置KPI警門需要監(jiān)控的KPI閾值門限值請參考2.5.2KPI控模板首先新建一個告警：登陸M2000，選擇菜單Performance->ThresholdManagement->AlarmNameSetting進添加一個新的告警名添加新告警成然后，為新建的告警設(shè)置對應(yīng)的KPI閾值：選擇菜單Performance->ThresholdManagement->ThresholdSetting進入KPI門限設(shè)置界面在左側(cè)的導航樹中選擇需要檢查的KPI類型在右側(cè)面板上單擊鼠標右鍵，選擇在BasicThresholdInformation面板中，選擇需要監(jiān)控的網(wǎng)元（對于SOP，建議是全部網(wǎng)元），給該門限在ExtendedThresholdInformation面板中，選擇具體要監(jiān)控的KPI項、指標惡化方向（升或降）及不同User-definedCounters章節(jié)。點擊“OK”即可以在Monitor->BrowseAlarmList啟動CPU用戶數(shù)性能監(jiān)啟動CPU用率監(jiān)登陸M2000，選擇菜單Monitor—>SignalingTrace>SignalingTrace選擇CPUUsage啟動用戶數(shù)監(jiān)登陸M2000，