901
某現(xiàn)場反映在某高鐵段，列車進入隧道后，4G數(shù)據業(yè)務無法使用，表現(xiàn)為進隧道視頻卡頓、網頁轉圈、微信消息發(fā)送接收失敗等。
信息收集
在收到問題反饋后，第一時間進行了如下信息收集。
1. 基站信息收集
故障涉及高鐵段123公里，共有18個隧道合計89公里。涉及運營商D 1.8G站點62個，313個小區(qū)；運營商D 800M站點60個，298個小區(qū)。
2. 組網信息收集
隧道內共有D、M、L三家運營商的設備5臺，由鐵塔POI合路后輸出兩根漏纜（一根為M和D共用，一根為M和L共用）發(fā)送信號，如圖1所示。
圖1 隧道內組網設備
設備詳細信息如下，組網劃分如圖2所示。
運營商M（FDD1800）：兩通道，無詳細信息。
運營商M（TDD F）：兩通道，1885-1915 MHz，2010-2025?MHz。
運營商D（800）：單通道，824-835?MHz，869-880?MHz。
運營商D（1.8G）：單通道，1735-1785?MHz，1830-1880?MHz。
運營商L（2.1G）：單通道，無詳細信息。
圖2 組網劃分
3. 網元數(shù)據收集
安排網元測試人員乘坐高鐵進行測試。隧道外宏站信號正常，隧道內占用運營商D的1800頻段，速率在100 kbps以內，無法正常使用數(shù)據業(yè)務；占用運營商M的F頻段，速率較低，為100 kbps~500 kbps；運營商L 2100頻段能正常使用。
測試以下場景并記錄數(shù)據：運營商D 800M鎖頻測試，運營商D 1800鎖頻測試，運營商D自由態(tài)測試，運營商M自由態(tài)測試，運營商D語音測試，運營商M語音測試。
4. 網管數(shù)據收集
網管側收集以下數(shù)據：
一鍵式信息采集。
XML配置文件。
組網拓撲關系圖，關聯(lián)的RRU機架號。
問題隧道站點KPI指標（流量、負荷、用戶數(shù)、RSSI、NI、上下行速率），選取無列車及列車通過時的兩個場景進行取數(shù)對比。
CQI、IMSI信令等。
數(shù)據分析
1. 網元測試數(shù)據分析
測試結果如圖3所示，對于全程平均RSRP，運營商D 800M頻段略差，1800頻段和運營商M差距不大；對于SINR和覆蓋率，運營商D的表現(xiàn)比運營商M好，但是下載速率明顯差于M。
圖3 測試數(shù)據
2. 網管數(shù)據分析
全路段信息匹配
通過基站告警信息跟蹤、基站KPI指標監(jiān)控、投訴信息匹配等，發(fā)現(xiàn)該路段站點無告警，全段KPI指標正常，也無用戶投訴。因此將問題聚焦到隧道內及隧道列車通過時的數(shù)據。
隧道內數(shù)據分析
從IMSI Log看，出現(xiàn)問題時下行調度MCS不錯，基本在20以上，但是反饋DTX太多（接近50%），如圖4和圖5所示。
圖4 下行MCS和RB數(shù)
圖5 下行反饋
重傳多會占用新傳調度機會（重傳調度優(yōu)先級高），所以下行流量存在問題。下行反饋DTX多是因為上行NI高，如圖6所示，PUSCH NI有跳變高現(xiàn)象，即不定時受到干擾。
圖6 PUCCH功率和NI
結論：列車經過時會導致NI抬升，優(yōu)先干擾到兩端RB，所以優(yōu)先考慮降NI。
現(xiàn)場測試
1. 隧道內NI排查
為了驗證影響NI的因素來自外部還是內部，現(xiàn)場申請了天窗進入到隧道進行測試。隧道口占用宏站信號速率正常，如圖7所示。
圖7 隧道口測試截圖
進入隧道內平均速率為70 Mbps，如圖8所示。核查POI接線無問題，接線端口分別為運營商D 1800、運營商M GSM1800和LTE F頻段?，F(xiàn)場進行超級小區(qū)拆分，拆分后速率降至50 Mbps，不影響用戶體驗，排除隧道內外部干擾。
圖8 隧道內測試圖
2. 列車內產生的外部干擾排查
初步懷疑列車WiFi信號使用的4G物聯(lián)網卡優(yōu)先級較高，導致系統(tǒng)帶寬被占用，以至于用戶在列車上進入隧道后無法使用移動信號?，F(xiàn)場申請了高優(yōu)先級測試卡再次到列車上進行測試排查，如圖9和圖10所示，高優(yōu)先級卡與普通卡效果是一樣的。
圖9 高鐵上隧道內速率（左起依次為D高優(yōu)先級卡、D低優(yōu)先級卡、M卡）
圖10 高鐵室外速率（左起依次為D高優(yōu)先級卡、D低優(yōu)先級卡、M卡）
幸運的是測試過程中去程列車WiFi故障，無法搜索到WiFi信號，回程列車WiFi正常，兩者進行了對比，依舊存在問題。在網管進行平權設置后，到列車上復測，進入隧道后依舊無法使用數(shù)據業(yè)務。因此推測列車上不存在外部干擾源。
3. 內部干擾定位
排除隧道內外部干擾和列車內外部干擾后，問題聚集到了內部干擾上。通過對組網的分析，POI屬于無源器件，而將各頻段通過POI接入，有可能會產生互調干擾從而導致運營商D頻段干擾。
經過對三階互調干擾的組合測算，如圖11所示，發(fā)現(xiàn)現(xiàn)場組網方式有三種組合產生的三階互調干擾會落在運營商D 1800頻段上。
組合一：M FDD1800+M FDD1800頻段與M F頻段組合三階互調。
組合二：M FDD1800+M FDD1800頻段與M FDD1800頻段組合三階互調。
組合三：M FDD1800+M F頻段與M F頻段組合三階互調。
圖11 三階互調組合（D 1800）
申請?zhí)齑斑M行驗證，進入隧道后通過三組測試進行三階互調干擾定位：
L手機飛行，D手機占用1.8G FDD，一部M手機鎖頻接入F頻段，進行連續(xù)下載業(yè)務，觀察運營商D FDD 1.8G NI。
L手機飛行，一部M手機鎖頻接入1800頻段，進行連續(xù)下載業(yè)務，觀察運營商D FDD 1.8G NI。
L手機飛行，D手機占用1.8G FDD，一部M手機鎖頻接入F頻段，另一部M手機鎖頻接入1800頻段，兩部M手機同時進行連續(xù)下載業(yè)務，觀察運營商D FDD 1.8G NI。
測試結果如圖12所示，通過三組測試驗證，手機在隧道內無列車通過時做業(yè)務，會抬升站點NI值。驗證結論:
單D小區(qū)，底噪不抬升。
D小區(qū)+M F頻段小區(qū)，D和M都做業(yè)務時，底噪不抬升。
D小區(qū)+M FDD1800頻段，底噪抬升。
D小區(qū)+M F頻段+M FDD1800，底噪抬升劇烈。
圖12 業(yè)務測試時頻譜掃描結果
最終結論：運營商M頻段與運營商D頻段共用一個POI會產生三階互調干擾，導致D數(shù)據業(yè)務無法使用。
故障處理
通過問題定位分析，確定了由于無源器件的三階互調干擾，導致了運營商D 1800頻段在列車經過時產生干擾，用戶無法使用數(shù)據業(yè)務。
解決方案一
為了從根本解決問題，從源頭（POI）出發(fā)，需要將運營商M的通道全部歸并到一個POI，D和L共用一個POI，將信號源從無源器件上分離，從而解決問題。
解決方案二
現(xiàn)場通過對POI的觀察，發(fā)現(xiàn)運營商L未使用1800頻段。通過對三階互調的計算，如圖13所示，僅有一種組合落在L 1800頻段內，理論上會比D 1800干擾值小。
圖13 三階互調組合（L 1800）
為了驗證可行性，現(xiàn)場申請?zhí)齑斑M入隧道。選取一個隧道內小區(qū)，將POI上D 1800端口更改至L 1800端口上，網管更改頻點、開啟站點。
復現(xiàn)場景，干擾值很低，不影響業(yè)務。列車通過時查看頻譜掃描結果，如圖14所示，波動很小。因此，D 1800三階互調干擾改為L 1800后干擾值減小，方案可行。
圖14 列車通過時L 1800頻譜掃描圖
解決方案三
通過共建共享方式，共享運營商L的2100頻段，將運營商D 1800設備拆除，既可以避免三階互調干擾，還可以進行資源盤活。
風險預警：通過對L 2100三階互調計算，如果運營商D和L用各自頻段各開20 MHz，共40 MHz，還將會產生三階互調干擾。如果只用2130 MHz~2150 MHz，就沒有三階互調，如圖15所示。
圖15 L 2100共建共享互調組合
