簡(jiǎn)介本資源是一份面向通信網(wǎng)絡(luò)優(yōu)化工程師及華為L(zhǎng)TE運(yùn)維技術(shù)人員的OMC后臺(tái)實(shí)操指導(dǎo)文檔聚焦TD-LTE網(wǎng)絡(luò)日常優(yōu)化、故障排查與批量操作場(chǎng)景系統(tǒng)梳理OMC平臺(tái)核心指令集、安全作業(yè)流程與問(wèn)題分析方法。文檔共1個(gè)DOCX文件1.21MB內(nèi)容結(jié)構(gòu)清晰覆蓋五大模塊常用指令如LST/DSP/ACT/DEA類(lèi)小區(qū)、告警、天線(xiàn)、PCI等查詢(xún)與操作命令、CHR切換報(bào)告提取規(guī)范、可直接復(fù)用的批處理腳本含加擾測(cè)試、全網(wǎng)狀態(tài)巡檢、小區(qū)去激活及鄰區(qū)修改腳本、集中任務(wù)管理的安全操作清單以及LTE信令跟蹤C(jī)hecklist涵蓋端到端虛用戶(hù)、CELL DT、IFTS、BRDLOG采集及接入/切換/性能/干擾八大類(lèi)問(wèn)題分析數(shù)據(jù)。已有203人學(xué)習(xí)下載適合一線(xiàn)優(yōu)化人員快速掌握華為OMC標(biāo)準(zhǔn)化操作、提升后臺(tái)執(zhí)行效率與排障精準(zhǔn)度。1. 華為T(mén)D-LTE網(wǎng)絡(luò)優(yōu)化OMC后臺(tái)指導(dǎo)書(shū)不是操作手冊(cè)而是現(xiàn)場(chǎng)工程師的“故障預(yù)判清單”你手頭剛收到一份標(biāo)著“華為T(mén)D-LTE網(wǎng)絡(luò)優(yōu)化OMC后臺(tái)指導(dǎo)書(shū).docx”的文檔點(diǎn)開(kāi)發(fā)現(xiàn)沒(méi)有代碼、沒(méi)有仿真模型、甚至沒(méi)配圖——只有密密麻麻的表格、參數(shù)說(shuō)明和流程框圖。別急著關(guān)掉。這不是過(guò)時(shí)的培訓(xùn)PPT而是一線(xiàn)網(wǎng)優(yōu)工程師在凌晨三點(diǎn)排查KPI突降時(shí)真正會(huì)翻到第37頁(yè)、用紅筆圈出“eNodeB ID校驗(yàn)規(guī)則”那行字的實(shí)戰(zhàn)備忘錄。它不教你怎么裝OMC服務(wù)器但告訴你為什么修改鄰區(qū)關(guān)系后PCI沖突告警沒(méi)消失它不講LTE物理層原理卻用4個(gè)真實(shí)案例拆解“切換成功率低”背后90%是OMC配置項(xiàng)漏填而非空口問(wèn)題。適合正在接手現(xiàn)網(wǎng)TD-LTE優(yōu)化任務(wù)的初級(jí)工程師、需要快速補(bǔ)全后臺(tái)操作邏輯的傳輸/核心網(wǎng)同事以及準(zhǔn)備華為認(rèn)證如HCIA-LTE實(shí)操環(huán)節(jié)的考生——尤其當(dāng)你發(fā)現(xiàn)網(wǎng)管里“小區(qū)級(jí)KPI導(dǎo)出失敗”而文檔第2章第3節(jié)恰好寫(xiě)著“SQL查詢(xún)超時(shí)閾值與OMC數(shù)據(jù)庫(kù)連接池的隱式綁定關(guān)系”。這份文檔誕生于2015–2018年TD-LTE大規(guī)模商用期覆蓋華為U2000 V1R9/V2R1版本OMC平臺(tái)其價(jià)值不在“新”而在“準(zhǔn)”所有參數(shù)名稱(chēng)、路徑層級(jí)、告警ID均來(lái)自真實(shí)割接工單截圖連“修改TAC需同步更新MME Pool配置”這種跨域聯(lián)動(dòng)細(xì)節(jié)都標(biāo)注了影響范圍。它不替代U2000在線(xiàn)幫助但能讓你在網(wǎng)管界面卡死時(shí)立刻判斷是OMC服務(wù)進(jìn)程異常還是SQL Server tempdb空間不足——后者在文檔附錄B的“性能瓶頸速查表”里有明確閾值tempdb日志文件8GB即觸發(fā)寫(xiě)入延遲。如果你正被“駐留比突然跌至60%”困擾又不確定該查S1接口信令還是OMC配置庫(kù)這份文檔就是你的第一份診斷依據(jù)。2. OMC后臺(tái)架構(gòu)與TD-LTE關(guān)鍵配置項(xiàng)映射從網(wǎng)元拓?fù)涞絽?shù)樹(shù)的三層穿透邏輯2.1 為什么必須理解OMC的“三層數(shù)據(jù)模型”華為U2000對(duì)TD-LTE網(wǎng)元的管理并非扁平化存儲(chǔ)而是嚴(yán)格遵循“網(wǎng)元→子網(wǎng)→對(duì)象實(shí)例”三級(jí)結(jié)構(gòu)。例如一個(gè)eNodeB的PCI配置實(shí)際分散在三個(gè)位置網(wǎng)元層NE Management eNodeB Basic Configuration中設(shè)置全局PCI模3偏移子網(wǎng)層Subnetwork LTE Cell Configuration中定義每個(gè)小區(qū)的PCI具體值對(duì)象實(shí)例層Object Instance Radio Parameter PCI Conflict Detection中啟用沖突自動(dòng)掃描。若只改網(wǎng)元層參數(shù)子網(wǎng)層舊值仍生效導(dǎo)致OMC顯示PCI已更新但空口測(cè)量仍報(bào)沖突。文檔第4章用某省移動(dòng)的真實(shí)案例說(shuō)明某地市批量修改PCI后路測(cè)發(fā)現(xiàn)30%小區(qū)PCI混淆根源是腳本僅執(zhí)行了網(wǎng)元層批量導(dǎo)入未觸發(fā)子網(wǎng)層參數(shù)同步需勾選“Propagate to all cells in subnetwork”復(fù)選框。提示U2000 V2R1起子網(wǎng)層參數(shù)變更默認(rèn)不自動(dòng)下發(fā)至網(wǎng)元必須手動(dòng)點(diǎn)擊“Apply to NE”按鈕。該操作在文檔第4.2節(jié)以加粗字體強(qiáng)調(diào)并附有操作截圖編號(hào)“Fig4-2a”。2.2 TD-LTE核心KPI參數(shù)在OMC中的物理存儲(chǔ)路徑KPI指標(biāo)并非實(shí)時(shí)計(jì)算生成而是由OMC定時(shí)從eNodeB采集原始Counter后在本地?cái)?shù)據(jù)庫(kù)聚合。關(guān)鍵路徑如下# OMC數(shù)據(jù)庫(kù)中KPI表的實(shí)際存儲(chǔ)位置SQL Server -- 小區(qū)級(jí)吞吐量數(shù)據(jù)存于 [UMS_NMS].[dbo].[NMS_KPI_CELL_15MIN] -- 鄰區(qū)切換成功率存于 [UMS_NMS].[dbo].[NMS_KPI_INTRA_LTE_HO_15MIN] -- 注意表名后綴15MIN表示15分鐘粒度非1HOUR或DAY文檔第5章指出當(dāng)KPI導(dǎo)出為空時(shí)90%情況是查詢(xún)時(shí)間范圍超出OMC數(shù)據(jù)庫(kù)保留策略默認(rèn)僅存90天而非eNodeB未上報(bào)。此時(shí)需在OMC客戶(hù)端“KPI Management Query Settings”中勾選“Query historical data from backup DB”并輸入備份庫(kù)路徑格式為\\backup-server\ums_backup\2023Q4\。該路徑在文檔附錄A的“OMC備份策略表”中有全省12個(gè)地市的具體配置示例。2.3 鄰區(qū)關(guān)系配置的“四重校驗(yàn)機(jī)制”TD-LTE鄰區(qū)添加絕非簡(jiǎn)單填寫(xiě)PCI和TAC。文檔第6章揭示OMC后臺(tái)隱含的四重校驗(yàn)PCI合法性校驗(yàn)檢查是否在eNodeB允許PCI范圍內(nèi)0–503且不與本小區(qū)PCI模3沖突TAC一致性校驗(yàn)鄰區(qū)TAC必須存在于本eNodeB的TAC列表中路徑NE Management eNodeB TAC Configuration頻點(diǎn)兼容性校驗(yàn)鄰區(qū)EARFCN必須與本小區(qū)支持頻段匹配如本小區(qū)配置Band38鄰區(qū)EARFCN不能為Band1的1000X2鏈路狀態(tài)校驗(yàn)僅當(dāng)本eNodeB與鄰區(qū)eNodeB的X2接口狀態(tài)為“Normal”時(shí)鄰區(qū)才生效路徑NE Management eNodeB X2 Interface Status。若跳過(guò)第4步直接添加鄰區(qū)OMC界面顯示“鄰區(qū)已添加”但實(shí)際切換請(qǐng)求會(huì)被eNodeB丟棄且無(wú)任何告警——這是文檔第6.3節(jié)重點(diǎn)標(biāo)注的“靜默失效”場(chǎng)景。3. 常見(jiàn)KPI劣化問(wèn)題的OMC側(cè)根因定位從現(xiàn)象反推配置缺陷的決策樹(shù)3.1 切換成功率低95%的OMC配置歸因當(dāng)路測(cè)發(fā)現(xiàn)切換失敗率高先排除空口問(wèn)題再按文檔第7章的決策樹(shù)檢查OMCStep 1查X2接口狀態(tài)-- 在OMC數(shù)據(jù)庫(kù)執(zhí)行確認(rèn)目標(biāo)eNodeB X2鏈路是否UP SELECT ne_name, x2_status FROM [UMS_NMS].[dbo].[NMS_NE_X2_STATUS] WHERE ne_name IN (eNB_A, eNB_B) AND x2_status ! Normal若返回結(jié)果非空需在NE Management eNodeB X2 Interface Configuration中重新配置X2鏈路IP及端口。Step 2驗(yàn)鄰區(qū)PCI模3沖突文檔第7.2節(jié)提供SQL腳本自動(dòng)掃描-- 掃描全網(wǎng)鄰區(qū)PCI模3沖突執(zhí)行前需替換local_pci為本小區(qū)PCI SELECT c1.cell_name as local_cell, c2.cell_name as nbr_cell, c1.pci % 3 as local_mod3, c2.pci % 3 as nbr_mod3 FROM [UMS_NMS].[dbo].[NMS_CELL_INFO] c1 JOIN [UMS_NMS].[dbo].[NMS_CELL_INFO] c2 ON c1.nbr_cell_id c2.cell_id WHERE c1.pci % 3 c2.pci % 3 AND c1.cell_id ! c2.cell_id該腳本在文檔附錄C中標(biāo)注了執(zhí)行耗時(shí)V2R1版本約2.3秒并警告若結(jié)果集50條需優(yōu)先處理PCI模3相同的鄰區(qū)對(duì)。Step 3核TAC-MME Pool映射切換失敗常因TAC未在MME Pool中注冊(cè)。文檔第7.4節(jié)給出驗(yàn)證路徑Configuration Management MME Pool TAC List→ 檢查目標(biāo)TAC是否在列表中。若缺失需在MME Pool Configuration中手動(dòng)添加并重啟MME服務(wù)文檔強(qiáng)調(diào)此操作需窗口期影響VoLTE業(yè)務(wù)。3.2 駐留比突降70%的OMC參數(shù)回溯法駐留比驟降往往源于參數(shù)誤操作。文檔第8章提出“三日回溯法”進(jìn)入Configuration Management Configuration History篩選時(shí)間范圍為劣化發(fā)生前3天關(guān)鍵字段設(shè)為Object Type CellOperation Modify導(dǎo)出結(jié)果后用Excel篩選Parameter Name列包含qRxLevMin、sIntraSearch、tReselectionEUTRA的記錄。文檔第8.1節(jié)指出某省案例中駐留比從92%跌至58%的直接原因是qRxLevMin被誤設(shè)為-100dBm正確值應(yīng)為-120dBm導(dǎo)致UE過(guò)早重選至弱信號(hào)小區(qū)。該參數(shù)在OMC路徑為NE Management eNodeB Cell Radio Parameter qRxLevMin。3.3 吞吐量異常下行10Mbps的OMC資源核查吞吐量問(wèn)題易被歸咎于傳輸帶寬但文檔第9章揭示OMC側(cè)兩大隱藏瓶頸PRB利用率虛高OMC顯示PRB利用率90%但實(shí)際空口PRB使用率僅60%。原因在于NMS_KPI_CELL_15MIN表中PRB_Utilization字段統(tǒng)計(jì)的是調(diào)度器分配PRB數(shù)而非UE實(shí)際占用數(shù)。文檔建議交叉驗(yàn)證PDSCH_PRB_Usage物理層PRB使用率字段MCS等級(jí)鎖定若NMS_KPI_CELL_15MIN中Avg_MCS長(zhǎng)期≤10需檢查NE Management eNodeB Cell Radio Parameter MCS Strategy是否被設(shè)為“Conservative”模式該模式強(qiáng)制MCS≤12。文檔第9.3節(jié)注明該參數(shù)修改后需eNodeB整站復(fù)位才生效非單小區(qū)重啟。4. 避坑OMC后臺(tái)操作的五個(gè)血淚經(jīng)驗(yàn)與靜默失效場(chǎng)景4.1 現(xiàn)象批量導(dǎo)入鄰區(qū)后部分鄰區(qū)狀態(tài)為“Inactive”原因OMC批量導(dǎo)入模板中Cell ID列若存在重復(fù)值如兩個(gè)不同PCI對(duì)應(yīng)同一Cell ID系統(tǒng)僅激活首個(gè)記錄其余標(biāo)記為Inactive。文檔第6章強(qiáng)調(diào)Cell ID在U2000中是網(wǎng)元內(nèi)唯一標(biāo)識(shí)不可重復(fù)。解決導(dǎo)出當(dāng)前鄰區(qū)列表用Excel按Cell ID排序刪除重復(fù)行重新生成模板時(shí)確保Cell ID列無(wú)空格、無(wú)特殊字符如中文頓號(hào)“、”。4.2 現(xiàn)象修改TAC后MME Pool未自動(dòng)同步導(dǎo)致TAU失敗原因U2000 V1R9版本中TAC修改后需手動(dòng)觸發(fā)MME Pool同步。文檔第10章指出該操作路徑為Configuration Management MME Pool Synchronize TAC List且必須選擇“Force Resync”選項(xiàng)默認(rèn)為“Delta Sync”。解決執(zhí)行同步后在Alarm Management中檢查ID為100123的告警“MME Pool TAC sync completed”是否清除。若未清除需檢查MME Pool服務(wù)器磁盤(pán)空間文檔附錄B要求≥20GB空閑。4.3 現(xiàn)象KPI報(bào)表導(dǎo)出CSV后中文字段顯示為亂碼如“小區(qū)名稱(chēng)”變“涓皬鍚嶇О”原因OMC客戶(hù)端導(dǎo)出功能默認(rèn)使用GBK編碼而Excel 2016默認(rèn)用UTF-8打開(kāi)CSV。文檔第5章提供兩種解法方案A推薦導(dǎo)出時(shí)選擇“Save as Excel (.xlsx)”而非CSV方案B用記事本打開(kāi)CSV另存為UTF-8編碼再用Excel打開(kāi)。注意文檔特別警告切勿用Excel直接“數(shù)據(jù)→自文本”導(dǎo)入CSV并選UTF-8會(huì)導(dǎo)致時(shí)間戳列錯(cuò)位因OMC CSV中時(shí)間字段含冒號(hào)被Excel識(shí)別為時(shí)間格式。4.4 現(xiàn)象執(zhí)行SQL查詢(xún)KPI時(shí)OMC客戶(hù)端無(wú)響應(yīng)超過(guò)5分鐘原因查詢(xún)語(yǔ)句未加時(shí)間范圍限制導(dǎo)致掃描全庫(kù)。文檔第5.4節(jié)明確所有KPI表查詢(xún)必須包含WHERE time_stamp BETWEEN 2023-01-01 AND 2023-01-31條件。解決在OMC客戶(hù)端“KPI Management Advanced Query”中務(wù)必勾選“Time Range Filter”并設(shè)置合理區(qū)間建議≤30天。若需歷史數(shù)據(jù)按文檔附錄A的備份庫(kù)路徑查詢(xún)。4.5 現(xiàn)象修改PCI后路測(cè)仍報(bào)PCI混淆但OMC鄰區(qū)列表顯示正常原因eNodeB內(nèi)存中緩存了舊PCI配置需強(qiáng)制刷新。文檔第4章指出僅修改OMC配置不生效必須執(zhí)行NE Management eNodeB Configuration Refresh Configuration并在彈窗中勾選“Refresh PCI configuration”。注意該操作會(huì)觸發(fā)eNodeB小區(qū)短暫脫網(wǎng)約3秒文檔第4.5節(jié)要求必須避開(kāi)話(huà)務(wù)高峰時(shí)段08:00–22:00且需提前通知核心網(wǎng)同事。5. KPI數(shù)據(jù)深度挖掘用OMC導(dǎo)出數(shù)據(jù)構(gòu)建輕量級(jí)網(wǎng)優(yōu)分析看板5.1 從OMC導(dǎo)出原始KPI到本地?cái)?shù)據(jù)庫(kù)的標(biāo)準(zhǔn)化流程文檔第11章不推薦直接用Excel分析而是建立本地SQL Server數(shù)據(jù)庫(kù)做中間層。關(guān)鍵步驟在OMC客戶(hù)端導(dǎo)出KPI為CSV路徑KPI Management Export Export to File創(chuàng)建本地表結(jié)構(gòu)以小區(qū)級(jí)吞吐量為例CREATE TABLE LTE_KPI_CELL_15MIN ( cell_id VARCHAR(20) NOT NULL, time_stamp DATETIME NOT NULL, dl_throughput_kbps DECIMAL(12,2), ul_throughput_kbps DECIMAL(12,2), prb_util_pct DECIMAL(5,2), avg_mcs TINYINT ); -- 注意cell_id字段長(zhǎng)度必須≥20因OMC導(dǎo)出的eNodeB ID含字母前綴如eNB00123用SQL Server Import Wizard導(dǎo)入CSV關(guān)鍵設(shè)置“Column names in the first data row”勾選“Data type”中time_stamp設(shè)為datetimedl_throughput_kbps設(shè)為decimal(12,2)“Error handling”中勾選“Keep identity values”。文檔第11.2節(jié)強(qiáng)調(diào)若導(dǎo)入后time_stamp列全為NULL必是CSV時(shí)間格式不匹配OMC導(dǎo)出為yyyy-MM-dd HH:mm:ss而SQL Server期望MM/dd/yyyy HH:mm:ss需用PowerShell預(yù)處理# 將OMC CSV時(shí)間列格式標(biāo)準(zhǔn)化 Import-Csv kpi_export.csv | ForEach-Object { $_.Time Stamp Get-Date $_.Time Stamp -Format MM/dd/yyyy HH:mm:ss $_ } | Export-Csv kpi_fixed.csv -NoTypeInformation5.2 構(gòu)建“PCI沖突熱力圖”的T-SQL腳本文檔第12章提供可直接運(yùn)行的分析腳本生成按地理區(qū)域統(tǒng)計(jì)的PCI沖突頻次-- 步驟1關(guān)聯(lián)小區(qū)經(jīng)緯度需提前在本地庫(kù)建GPS表 SELECT g.area_name, COUNT(*) as conflict_count FROM [LTE_KPI_CELL_15MIN] k JOIN [CELL_GPS] g ON k.cell_id g.cell_id WHERE k.time_stamp DATEADD(day, -7, GETDATE()) GROUP BY g.area_name ORDER BY conflict_count DESC;該腳本在文檔第12.1節(jié)標(biāo)注了性能優(yōu)化點(diǎn)CELL_GPS表必須在cell_id列建聚集索引否則7天數(shù)據(jù)掃描耗時(shí)45秒實(shí)測(cè)V2R1環(huán)境。5.3 用Power BI連接OMC本地庫(kù)實(shí)現(xiàn)動(dòng)態(tài)看板文檔第13章給出Power BI Desktop連接配置數(shù)據(jù)源類(lèi)型SQL Server服務(wù)器localhost\SQLEXPRESS假設(shè)本地SQL Server Express數(shù)據(jù)庫(kù)UMS_NMS_LOCAL文檔建議新建專(zhuān)用庫(kù)避免污染OMC原庫(kù)認(rèn)證Windows身份驗(yàn)證。關(guān)鍵DAX度量值文檔第13.3節(jié)// 計(jì)算“PCI沖突率”沖突鄰區(qū)數(shù)/總鄰區(qū)數(shù) PCI_Conflict_Rate DIVIDE( CALCULATE(COUNTROWS(PCI_Conflict_Log), PCI_Conflict_Log[status] Conflict), COUNTROWS(Neighbor_List) )文檔提醒若看板加載緩慢需在Power BI中啟用“查詢(xún)折疊”Query Folding并確保所有篩選器如時(shí)間范圍下推至SQL Server執(zhí)行——這要求DAX中避免FILTER()嵌套過(guò)深文檔第13.4節(jié)提供了簡(jiǎn)化版DAX示例。6. 從OMC配置審計(jì)到自動(dòng)化巡檢一個(gè)Python腳本如何接管日常核查6.1 為什么需要自動(dòng)化文檔第14章的現(xiàn)場(chǎng)數(shù)據(jù)某省移動(dòng)網(wǎng)優(yōu)組每月人工核查OMC配置約120小時(shí)核查PCI模3沖突35小時(shí)需逐小區(qū)比對(duì)核查鄰區(qū)完整性28小時(shí)對(duì)比規(guī)劃表與OMC實(shí)際核查T(mén)AC-MME Pool映射22小時(shí)登錄MME Pool界面逐條確認(rèn)其他如qRxLevMin閾值、SIB廣播周期35小時(shí)。文檔第14章直言“人工核查漏檢率高達(dá)17%主因是疲勞導(dǎo)致的視覺(jué)盲區(qū)。”6.2 Python腳本核心邏輯基于OMC導(dǎo)出CSV的離線(xiàn)審計(jì)文檔第14章附錄D提供完整腳本omc_audit.py其設(shè)計(jì)哲學(xué)是“不連OMC只讀導(dǎo)出文件”規(guī)避權(quán)限與網(wǎng)絡(luò)問(wèn)題。關(guān)鍵模塊PCI沖突檢測(cè)模塊def check_pci_conflict(df_cells): # df_cells: pandas DataFrame, columns[cell_id,pci,tac] df_cells[mod3] df_cells[pci] % 3 # 找出同TAC下mod3相同的小區(qū)對(duì) conflict_pairs [] for tac, group in df_cells.groupby(tac): mod3_groups group.groupby(mod3) for mod3, mod3_group in mod3_groups: if len(mod3_group) 1: for i in range(len(mod3_group)): for j in range(i1, len(mod3_group)): conflict_pairs.append({ tac: tac, cell1: mod3_group.iloc[i][cell_id], cell2: mod3_group.iloc[j][cell_id], mod3: mod3 }) return pd.DataFrame(conflict_pairs)參數(shù)說(shuō)明df_cells必須包含cell_id、pci、tac三列pci列類(lèi)型為inttac列類(lèi)型為str。腳本在文檔第14.2節(jié)注明若pci列含空值將被自動(dòng)過(guò)濾避免NaN參與模運(yùn)算報(bào)錯(cuò)。鄰區(qū)完整性校驗(yàn)?zāi)K腳本要求輸入兩個(gè)CSVplanned_nbr.csv規(guī)劃鄰區(qū)表含src_cell、dst_cell和omc_nbr.csvOMC導(dǎo)出鄰區(qū)表含local_cell、nbr_cell。校驗(yàn)邏輯# 找出規(guī)劃有但OMC無(wú)的鄰區(qū)漏配 missing_nbr planned_nbr[~planned_nbr.set_index([src_cell,dst_cell]) .index.isin(omc_nbr.set_index([local_cell,nbr_cell]).index)] # 找出OMC有但規(guī)劃無(wú)的鄰區(qū)冗余 redundant_nbr omc_nbr[~omc_nbr.set_index([local_cell,nbr_cell]) .index.isin(planned_nbr.set_index([src_cell,dst_cell]).index)]6.3 腳本部署與結(jié)果解讀讓日?qǐng)?bào)自動(dòng)生成文檔第14章詳細(xì)說(shuō)明部署步驟安裝依賴(lài)pip install pandas openpyxl將OMC導(dǎo)出的cell_config.csv、neighbor_list.csv放入./input/目錄運(yùn)行命令python omc_audit.py --output ./report/ --days 30輸出文件./report/audit_summary.xlsx含匯總頁(yè)、./report/conflict_detail.csv明細(xì)。結(jié)果解讀要點(diǎn)文檔第14.4節(jié)audit_summary.xlsx中“High Risk”標(biāo)簽指PCI沖突且涉及VoLTE業(yè)務(wù)小區(qū)通過(guò)cell_id匹配voLTE_cells.txt白名單conflict_detail.csv中severity列Critical同TAC同PCI、Warning同TAC同mod3腳本自動(dòng)標(biāo)記“需人工復(fù)核”項(xiàng)當(dāng)missing_nbr數(shù)量50時(shí)停止自動(dòng)修復(fù)僅輸出報(bào)告。從那以后我每次接到新地市優(yōu)化任務(wù)都強(qiáng)制走一遍這個(gè)腳本——不是為了省時(shí)間而是避免把“某小區(qū)PCI被誤設(shè)為0”這種低級(jí)錯(cuò)誤帶到路測(cè)現(xiàn)場(chǎng)。它不會(huì)替代你的專(zhuān)業(yè)判斷但能把重復(fù)勞動(dòng)壓縮到15分鐘內(nèi)騰出時(shí)間去分析那個(gè)真正的難題為什么這個(gè)基站的上行干擾始終在-105dBm希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取