LTE日常維護案例介紹doc資料.ppt

LTE日常維護案例介紹 目錄 業(yè)務(wù)類故障處理 設(shè)備類故障處理 傳輸類 設(shè)備類故障處理 射頻類 設(shè)備類故障處理 硬件更換類 傳輸類故障 傳輸類故障處理 傳輸類故障 傳輸故障處理思路 總體思路 分層 逐段排查定位分層法 根據(jù)協(xié)議層 逐層定位 定位出實際故障點 逐段法 完成故障隔離 對數(shù)據(jù)流進行分段 逐段環(huán)回 逐段定位 具體排查項 物理層故障排查ARP IP層故障排查IPPATH異常處理SCTP異常處理問題定界指導 傳輸類故障 傳輸故障逐層排查方法簡介 抓包 維護通道類故障 維護通道類故障處理 DHCP 站點 2 自動發(fā)現(xiàn) U2000 S W CME 中心機房 Support網(wǎng)站 1 1 提取版本包 1 2 組織配置數(shù)據(jù) 1 4 打開開站工具 上傳數(shù)據(jù) 啟動開站 上報ESN 4 調(diào)測License下發(fā) 1 安裝上電 3 自動配置 Config S W 限制和約束 在開站之前 必須 硬件安裝完畢 U2000調(diào)測完畢 eNodeB與U2000之間的傳輸正常 eNodeB的軟件版本必須從Support網(wǎng)站上取得 并且已經(jīng)上傳到U2000Server 1 3 導出開站列表 DHCP自發(fā)現(xiàn)失敗 典型故障 DHCP自發(fā)現(xiàn)失敗故障處理 實現(xiàn)原理 1 為了避免DHCP廣播包沖擊U2000 引入路由器進行DHCPRelay 轉(zhuǎn)化為單播報文 2 DHCP過程目的是實現(xiàn)eNodeB的OMCH的建立 即獲取IP 路由等 2 eNodeB上電后 4步完成DHCP過程 常見問題需分析具體消息中的取值DHCPDISCOVERDHCPOFFERDHCPREQUESTDHCPACK DHCP流程 該流程分四步 1 基站在檢測到可用的鏈路后 廣播DHCPDISCOVER報文 以查找可用的U2000 2 U2000進行ESN匹配 如果匹配成功 U2000會發(fā)送DHCPOFFER報文給L3交換機 并攜帶分配的IP地址等信息 以響應DHCPDISCOVER 3 eNB收到DHCPOFFER后 判斷ESN是否正確 如果正確 則停止DHCP探測過程 并發(fā)送DHCPREQUEST廣播報文 向U2000服務(wù)器發(fā)起確認信息 4 U2000同樣需要進行ESN匹配判斷 確認信息正確后發(fā)送DHCPACK報文給eNB 基站收到DHCPACK報文 進行ESN匹配 匹配成功后 分配的IP地址等信息生效 并生成OMIP和相關(guān)路由信息 維護通道類故障 DHCP自發(fā)現(xiàn)失敗故障處理 問題描述某局點 在站點安裝完成并加電后 使用U2000進行自開站 發(fā)現(xiàn)某站點在發(fā)送OFFER報文后 在DHCP配置管理中一直未出現(xiàn)上報的REQUEST報文 問題原因在U2000抓包看 已收到eNodeB上報REQUEST報文 但在上報的REQUEST中未攜帶OPTION54字段 因此導致該站的REQUEST報文被U2000拋棄 同時 在基站側(cè)鏡像抓包后證明基站發(fā)送的REQUEST報文已攜帶OPTION54字段 結(jié)論 IPRAN修改了DHCP報文 丟棄了OPTION54字段 維護通道類故障 VLAN自學習失敗故障處理 問題描述W市T運營商LTE工程在開站過程中DHCP四個報文都是正常的 從U2000上可以看到已經(jīng)下發(fā)ACK消息到基站 且基站也收到U2000發(fā)送的ACK消息 但是ACK消息之后又重復DHCP四個報文 導致基站操作維護鏈路一直不能建立 1 首先進行現(xiàn)象確認 DHCP過程正常 而OM通道建立失敗 可能是由于DHCP過程中下發(fā)的配置有誤或者是傳輸側(cè)配置有誤 2 其次進行配置核查 結(jié)合現(xiàn)象核查DHCP下發(fā)的配置 DHCP下發(fā)的主要配置如圖所示 核查后發(fā)現(xiàn)配置參考與規(guī)劃相同 3 再次進行傳輸側(cè)相關(guān)參數(shù)核查 主要是與OM通道相關(guān)的配置 如VLAN 網(wǎng)關(guān)IP 核查后發(fā)現(xiàn)VLAN配置與規(guī)劃不一致 修改summary表中基站的VLAN 重新導入CME中 重新導出開站數(shù)據(jù)和開站列表 開站正常 處理過程 維護通道類故障 VLAN自學習失敗故障處理 VLAN自學習 在U2000上創(chuàng)建PnP調(diào)測任務(wù)后 U2000周期性向基站發(fā)送OM通道建立請求 該報文的源IP地址為U2000IP地址 目的IP地址為基站的OMIP地址 此數(shù)據(jù)包會被發(fā)送至基站側(cè)Relay的L3路由器上 如果L3路由器上無對應此報文目的IP地址及eNBOMIP的ARP表項 L3設(shè)備就會廣播ARP報文 此時基站則會接收到此ARP報文 并從ARP報文中取出正確的VLAN信息同時進行保存 重點 基站學習到的VLAN是IPRANL2上配置的VLAN 1 DHCP四個報文中從基站上報的discover和request報文中的VLAN都是從IPRANL2上學習到的 所以基站所發(fā)的這兩個報文能正常到達U2000 而U2000也可以把offer和ack報文發(fā)送到基站 2 U2000給基站下發(fā)ACK消息后 基站會把從U2000上配置的操作維護IP VLAN和路由在基站側(cè)生效 在建立操作維護之前基站會使用U2000ACK消息中的VLAN和IPRANL2上配置的VLAN進行對比 如果一致會建立操作維護鏈路 如果不一致則把從ACK消息中獲取到的IP 路由及VLAN全部失效 重新啟動DHCP流程 案例根因 傳輸類案例 傳輸引起的開站失敗案例 問題現(xiàn)象某局點 在進行開站時 發(fā)現(xiàn)從U2000上看 每次開站時都是進行到99 時 失敗 排查步驟1 首先進行現(xiàn)象確認 從U2000開站界面上可以看到基站已完成了版本下載 配置下載 在進行激活配置后等待站點重新啟動完成時超時 2 其次進行配置核查 版本能夠下載成功 說明ESN無誤 VLAN IP和路由沒有問題 復位后OMCH建立失敗 可能原因是版本和配置文件激活失敗 或激活成功后OMCH通道建立失敗 核查結(jié)果版本與配置文件匹配 沒有問題 端口模式 VLAN IP 路由配置均無誤 3 再次進行傳輸側(cè)相關(guān)參數(shù)核查 發(fā)現(xiàn)ATN的端口協(xié)商模塊為強制 實際要求為自適應 改為自適應后 開站成功 此處失敗 目錄 業(yè)務(wù)類故障處理 設(shè)備類故障處理 傳輸類 設(shè)備類故障處理 射頻類 設(shè)備類故障處理 硬件更換類 射頻類故障 射頻類故障處理 1 2 3 RSSI 外部干擾 互調(diào) 駐波 CPRI接口 電調(diào)天線故障 射頻類故障 RSSI故障處理 RSSI過低 RSSI不平衡 RSSI過高 RSSI RSSI理論值 1 2 方法1 方法2 1 記錄空載時的RSSI值 2 通過ADDCELLSIMULOAD加載模擬負載 3 在U2000跟蹤RSSI差值是否大于4dB 1 通過STRRFTEST進行反向互調(diào)干擾檢測 過低告警門限為 114dBm 空載下RSSI的計算方法如下 174 10 logBW NF 其中BW為帶寬 單位為Hz NF為射頻模塊的噪聲系數(shù) 通常為2 2 5左右 舉例 LRRU2 6G2T2R 5MHz小區(qū)帶寬 那么空載下的RSSI參考值大小 174 10 log 5 10 6 2 5 104 5dBm RSSI過高 標準要求不超正常值6dB 因此20M RSSI 92dBm 15M RSSI 93dBm 3 頻譜掃描 OK NOK 射頻類故障 RSSI故障處理 先按要求進行后臺單站測試 加載和不加載的時候RSSI差值大于等于4dBm的定義為內(nèi)部干擾 工程質(zhì)量問題和互調(diào)問題 需安排站處理恢復 如果RSSI值高于 92dBm 排除測試方法 駐波 射頻通道告警等問題后 就可以認為 疑似存在外部干擾 需要網(wǎng)優(yōu)人員上站掃頻 如果客戶掃頻掃不出干擾 作為重點問題 由客戶及網(wǎng)優(yōu) 產(chǎn)品人員一起上站去排查處理 如掃頻掃出干擾 處理干擾問題 備注 主分集RSSI均偏高且基本一致 優(yōu)先考慮外部干擾問題 主分集RSSI只有一個偏高 且相差較大 優(yōu)先考慮互調(diào)問題 射頻類故障 互調(diào)問題處理 目前商用的互調(diào)測試儀都只能測試天饋系統(tǒng)的互調(diào)大小 無法定位出互調(diào)故障點的位置 在這種情況下 業(yè)界最成熟也是廣泛采用的互調(diào)故障點定位方法是 分段排查法 或者使用 替換法 逐段饋線檢查替換 分段排查法 如下圖所示 射頻類故障 電調(diào)天線故障處理 電調(diào)基本原理 遠程電調(diào)天線RET RemoteElectricalTilt 由天線 遠端控制單元RCU RemoteControlUnit 和AISG AntennaInterfaceStandardGroup 控制線纜組成 見圖1 兩種連接方式 RRU RFU SBT RCU和RRU RCU 射頻類故障 電調(diào)天線故障處理 配置步驟 電調(diào)天線調(diào)測過程 通過網(wǎng)管遠程控制 第一步 設(shè)置ALD供電開關(guān)MODRETPORT RRU直接給RCU供電方式 MODANTENNAPORT 使用SBT或塔放給RCU供電方式 第二步 掃描ALD設(shè)備SCNALD第三步 添加ALD設(shè)備ADDRET第四步 配置電調(diào)天線與RRU的對應關(guān)系MODRETSUBUNIT第五步 加載RET天線配置數(shù)據(jù)文件DLDRETCFGDATA第六步 校準RET天線CLBRET第七步 設(shè)置RET天線下傾角MODRETTILT第八步 查詢RET天線下傾角DSPRETSUBUNIT 射頻類故障 電調(diào)天線故障處理 常見電調(diào)故障 射頻類故障 駐波故障處理 射頻類故障 CPRI接口故障處理 射頻類故障 射頻類故障處理案例 華為LTE基站RRU光路異常分析 目前LTE基站基本采用DBS3900方式組網(wǎng) 因此BBU RRU的光路故障是我們?nèi)粘＞S護中最經(jīng)常遇到的問題之一 這類故障常見的告警包括 告警類別那么多 嚇死人了 射頻類故障 射頻類故障處理案例 華為LTE基站RRU光路異常分析 其實 沒有那么復雜 BBU RRU光路涉及的設(shè)備就那么幾個 你說能復雜到哪去呢 是吧 下面我們來分析看看 BBU和RRU尾纖直連 BBU和RRU中間轉(zhuǎn)接光路 BBU和RRU尾纖接ODF架 處理方式 后臺查詢1 通知后臺查詢BBU光模塊的收發(fā)光功率是否正常 2 如果RRU沒有中斷 查詢RRU光模塊的收發(fā)光功率是否正常 通過后臺的光功率查詢 可以初步判斷故障原因是光衰過大還是鏈路中斷 射頻類故障 射頻類故障處理案例 華為LTE基站RRU光路異常分析 現(xiàn)場排查 建議攜帶 光功率計 光模塊 短尾纖 做以下操作前可以先查看光模塊規(guī)格是否正確 拔插光模塊 尾纖 查看尾纖頭是否有塵灰等 以下4個步驟 基本可以完成故障的排查和處理 其實挺簡單的吧 所以不要在檢查前隨意就換了光模塊或者RRU哦 1 用尾纖在BBU光口環(huán)回 和后臺確認BBU的光模塊收發(fā)光是否正常 如果正?？梢耘懦鼴BU端口和光模塊問題 否則請按順序更換BBU光模塊 端口 單板直到環(huán)回BBU光模塊收發(fā)光正常 2 在BBU側(cè)用光功率計測量RRU過來的光功率是否正常 如果不正常 檢查下一步 3 在RRU測量RRU發(fā)出的光功率 如果正常 請檢查光路 如果不正常 請按順序更換光模塊 RRU端口 RRU直至發(fā)出的光功率正常 4 在RRU處測量BBU過來的光功率 如果不正常 請檢查光路 如果正常 請按順序更換光模塊 RRU端口 RRU直至正常 射頻類故障 射頻類故障處理案例 1 問題現(xiàn)象 上報ALM 26529射頻單元駐波告警 重要 與ALM 29243小區(qū)服務(wù)能力下降告警問題分析 如果駐波告警后處理開關(guān)打開 上報重要級別射頻單元駐波告警 將關(guān)閉駐波告警對應的發(fā)射通道 觸發(fā)小區(qū)服務(wù)能力下降告警 此時先處理駐波告警如果未打開駐波告警后處理開關(guān) 則兩個告警分別排查 問題處理步驟1 查詢駐波告警門限 確認門限配置正確 LSTRRU 默認駐波門限2 0 駐波后處理門限3 0 2 離線駐波測試 確認駐波檢測的結(jié)果確實高 輸入小區(qū)的下行中心頻率 避免天饋組件中存在頻段不匹配的組件 如合路器等 導致測試的結(jié)果錯誤 3 上站排查 發(fā)現(xiàn)駐波異常的通道天饋線纜斷開 重新連接好后測試駐波恢復 射頻類故障 射頻類故障處理案例 2 問題描述 上報ALM 26521射頻單元接收通道RTWP RSSI過低告警 問題處理步驟 確認是否存在ALM 26532射頻單元硬件故障告警 如果存在按告警幫助處理 不存在 2 排查接收通道衰減配置 如果有塔放 塔放是否正常工作 沒有使用塔放 且通道衰減為0 沒有問題 3 復位射頻單元 復位后不恢復 帶備件上站排查 4 交換射頻單元正常與異常通道的天饋連接 交換后射頻單元未隨天饋轉(zhuǎn)移 5 更換射頻單元后恢復 待返板分析 射頻類故障 射頻類故障處理案例 3 問題描述 上報ALM 29243小區(qū)服務(wù)能力下降告警問題分析 1 配置與單板實際支持規(guī)格不符 小區(qū)配置的 小區(qū)發(fā)送和接收模式 大于RRU實際支持的規(guī)格 例如配置2T4R小區(qū) RRU實際只能支持2T2R RRU實際支持的規(guī)格可以通過查詢RRU電子標簽確認 2 小區(qū)配置的 小區(qū)發(fā)送和接收模式 大于LBBP實際支持的規(guī)格 例如配置2T4R小區(qū) LBBP實際只能支持2T2R LBBP實際支持的規(guī)格可以通過產(chǎn)品文檔 硬件描述 確認 3 如果是SFN小區(qū) 由于配置錯誤或RRU不可用導致配置的 SFN小區(qū)扇區(qū)設(shè)備數(shù)量 與實際可用的扇區(qū)設(shè)備數(shù)量不一致修改 SFN小區(qū)扇區(qū)設(shè)備數(shù)量 與實際一致 或解決RRU不可用問題 MODCELL LocalCellId 0 MultiRruCellFlag BOOLEAN TRUE MultiRruCellMode SFN SectorEqmNum n 4 CPRI帶寬不足DSPCPRILBR查詢當前協(xié)商到的線速率 將該速率與實際配置所需的CPRI速率進行對比 如果小于實際配置所需CPRI速率 CPRI不壓縮場景下 20M 15M2T2RCPRI接口帶寬需求為2 5Gbps 20M 15M2T4RCPRI接口帶寬需求為4 9Gbps 具體計算可參考2013年FAQ CPRI接口速率如何計算 則根據(jù) 最大速率能力 部分的描述判斷是RRU側(cè)的光模塊還是LBBP側(cè)的光模塊速率過低導致 同時可以通過DSPSFP確認光模塊的詳細信息 如果光模塊速率正確 但是協(xié)商到的速率小于兩側(cè)光模塊的速率 則有可能是CPRI鏈路其它故障導致 射頻類故障 射頻類故障處理案例 3 5 射頻單元發(fā)射通道或接收通道關(guān)閉查看是否存在26259 射頻單元駐波告警 26545 射頻單元發(fā)射通道手動關(guān)閉告警 26532 射頻單元硬件故障告警 26538 射頻單元時鐘異常告警 26524 射頻單元功放過流告警 如果存在先排除告警 注意 在射頻單元駐波告警后處理開關(guān)關(guān)閉 通過LSTRRU查詢 時 不會因為駐波大于駐波比告警后處理門限 默認值3 關(guān)閉發(fā)射通道 故此時不會導致小區(qū)服務(wù)能力下降告警 6 CPRI鏈路異常查看是否存在26230 BBUCPRI光模塊異常告警 26232 BBU光模塊收發(fā)異常告警 26233 BBU光接口性能惡化告警 26234BBUCPRI接口異常告警 26503 射頻單元光模塊收發(fā)異常告警 26504 射頻單元CPRI接口異常 26506 射頻單元光接口性能惡化告警 如果存在先排除告警 問題處理步驟 確認小區(qū)配置實際單板規(guī)格是否支持 小區(qū)配置2T4R RRU3632 LBBPd3單板 CPRI未壓縮時 2T4R20M小區(qū)需要4 9GCPRI速率 查看CPRI協(xié)商結(jié)果 從線速率上確認 CPRI速率不足導致小區(qū)服務(wù)能力下降 DSPSFP或DSPELABLE查詢光模塊支持的速率 確認為LBBP側(cè)使用了2 5G光模塊 更換光模塊告警恢復 射頻類故障 射頻類故障處理案例 4 問題描述 出現(xiàn) 電調(diào)天線馬達故障告警 和 電調(diào)天線未校準告警 華為雙頻六端口天線替換原C網(wǎng)天線并安裝華為RRU3638 C網(wǎng)天線的RCU先級聯(lián)到LTE天線的RCU上 然后將RCU通過AISG電纜連接到RRU3638 通過網(wǎng)管對站點3個小區(qū)進行電調(diào)數(shù)據(jù)加載 總顯示校準失敗 多次校準后出現(xiàn)3個小區(qū)LTE側(cè)電調(diào)馬達永久堵轉(zhuǎn)現(xiàn)象 問題分析 1 RCU馬達硬件故障 2 RCU的電壓供電不足會導致馬達驅(qū)動力不足 RCU線接觸不良 線未擰緊等 或RCU線過長 饋線饋線松動 過長都可能導致供電不足3 加載的配置文件與RCU不匹配 射頻類故障 射頻類故障處理案例 4 問題處理步驟 1 加載電調(diào)數(shù)據(jù) 顯示校準失敗 通過DSPRETPORT查看端口電流值 均顯示正常范圍 2 SCNALD掃描電調(diào)天線 并不存在序列號錯誤的現(xiàn)象 3 刪除電調(diào)數(shù)據(jù) RSTALD復位天線設(shè)備 復位RRU 重新加載數(shù)據(jù) 仍顯示電調(diào)未校準 4 需上站處理了 但是3個小區(qū)都出現(xiàn)馬達堵轉(zhuǎn)硬件故障的幾率很小 則懷疑加載電調(diào)數(shù)據(jù)時綁定RCU序列號可能出現(xiàn)LTE側(cè)和C網(wǎng)側(cè)混淆 則刪除數(shù)據(jù) 將每個小區(qū)電調(diào)序列號LTE側(cè)和C網(wǎng)側(cè)互換 重新加載電調(diào)數(shù)據(jù) 加載成功 目錄 業(yè)務(wù)類故障處理 設(shè)備類故障處理 傳輸類 設(shè)備類故障處理 射頻類 設(shè)備類故障處理 硬件更換類 U2000FDD LTE的UMPT板故障恢復指導書 在現(xiàn)實LTE網(wǎng)絡(luò)運維中 基站單板故障不可避免 LTE網(wǎng)絡(luò)沒有了基站控制器 其運行配置全部儲存在基站上 因此更換主控板時 需要完全更新數(shù)據(jù) 華為網(wǎng)管集成了CME對數(shù)據(jù)進行管理 通過CMECurrent區(qū)實時同步網(wǎng)元配置的功能 可以實現(xiàn)不需要重新開站而只需要利用已保存的數(shù)據(jù)完成快速建站 達到更換主控板前的站點狀態(tài) 需要在現(xiàn)場更換單板前完成Step1 Step3步驟工作 否則網(wǎng)管數(shù)據(jù)可能會被新更換單板數(shù)據(jù)覆蓋 1 刪除即插即用中原來的基站數(shù)據(jù) 注意記錄基站ESN號 2 進入CME Current區(qū) 打開Current區(qū) 導出目標站點的 即插即用數(shù)據(jù) 3 校驗完成后 進入 即插即用 界面 點擊進行重新開站 4 更換主控板 待開站正常結(jié)束 5 檢查數(shù)據(jù)配置是否與之前相同 及基站各項狀態(tài)是否正常 目錄 業(yè)務(wù)類故障處理 設(shè)備類故障處理 傳輸類 設(shè)備類故障處理 射頻類 設(shè)備類故障處理 硬件更換類 業(yè)務(wù)類故障處理案例1 問題描述某LTEFDD站點下只能接入一個終端 第二個終端無法連接上 后來更換多個終端 發(fā)現(xiàn)有的可以接入 有的則不行告警信息 無版本 V100R008C01SPC240 問題分析 1 用戶接入類問題 首先排查終端問題 是否只涉及某一類終端 其次確認失敗時現(xiàn)象 是否網(wǎng)絡(luò)無響應 還是已接入無法做業(yè)務(wù) 2 接入失敗 要通過信令確認在哪一個階段被拒絕 是RRC階段還是E RAB階段 LTE系統(tǒng)中的承載如下圖所示 業(yè)務(wù)類故障處理案例1 問題處理步驟 1 通過跟蹤可以看到UE會給MME回復S1AP INITIAL CONTEXT SETUP RSP消息后 等待了52秒給MME又發(fā)送了釋放請求 原因為傳輸資源不可用 2 S1AP INITIAL CONTEXT SETUP REQ攜帶的地址如下 解析后為10 100 34 68 1 3 查看告警情況測試時間段28號告警上報情況是正常的 到10 100 34 68無異常告警 業(yè)務(wù)類故障處理案例1 4 從CHR統(tǒng)計可以看到90 的掉話都是由于UEM UECNT REL RECV GTPU RESET BEAR REQ 導致RAB階段掉話 這個錯誤值的含義是RRC重建 重配置GTPU資源失敗 5 查看CHR日志 選取了多次失敗記錄看 都指向不同的對端IP 有10 100 34 12 10 100 34 65 10 100 34 34等等 如下圖只是一個舉例 說明并不是某一條鏈路存在問題 所有鏈路都有問題 再看對應釋放時間點的debug日志 看到有GTPU的EchoResponse超時記錄 以及明顯的IPPATHdown的記錄 說明是IPPATH鏈路故障導致對端沒有回EchoResponse 6 檢查傳輸鏈路 對所有對端IP進行PING測試 500字節(jié)20次包大部分都能PING通 1500字節(jié)基本不能通 調(diào)整到1472能PING通 1473字節(jié)PING不通 說明傳輸MTU存在瓶頸 設(shè)置的MTU值不滿足我們的要求 要求傳輸更改MTU值或者更換傳輸鏈路 7 由于當前使用異廠家傳輸 修改MTU未協(xié)調(diào)成功 修改到華為傳輸下 ping1500字節(jié)能通 業(yè)務(wù)測試正常 業(yè)務(wù)類故障處理案例1 案例中IPPATH故障卻未上報告警 IPPATH故障是否有檢測機制 是否會上報告警 如果打開了GTPU靜態(tài)檢測 MODGTPU IPPATH會通過GTPUECHO報文檢測業(yè)務(wù)通道 檢測機制根據(jù)配置MODGTPU來定的 默認是20s一次 連續(xù)3次才上報告警 LSTGTPU 查詢GTPU配置信息 ECHO幀超時時長 毫秒 20000ECHO幀超時次數(shù) 3差分服務(wù)碼 0靜態(tài)檢測開關(guān) 使能 靜態(tài)檢測 1分鐘檢測一輪 1分鐘定時器超時后 在所有IPPATH上發(fā)送GTPUECHO檢測報文 收到SGW應答 檢測正常結(jié)束 檢測不通 等待 ECHO幀超時時長 MODGTPU設(shè)置 默認5秒 后 發(fā)送下一個報文 一共發(fā)送 ECHO幀超時次數(shù) MODGTPU設(shè)置 默認3次 超時后上報 IPPath故障告警 Link方式 或 用戶面承載鏈路故障告警 End Point方式 動態(tài)檢測 只檢測有用戶承載的IPPATH 檢測機制與靜態(tài)相同 檢測到故障后不上報告警 會釋放對應IPPATH上的承載用戶 接入類故障 接入類常見故障處理 當出現(xiàn)終端無信號情況時 首先檢查小區(qū)是否正常開工 排查基站側(cè)告警 2 小區(qū)正常后 仍無法搜到網(wǎng)絡(luò) 則確認終端是否支持LTE對應頻段 FDD TDD模式 3 終端發(fā)起attach流程后 未發(fā)起鑒權(quán)就被MME拒絕 一般原因為終端在EPC側(cè)的開戶數(shù)據(jù)存在異常 需要協(xié)調(diào)EPC配合定位 4 終端與EPC雙向鑒權(quán)失敗 導致終端被拒絕接入 一般原因為寫卡的KI OP OPC與開戶的KI OP OPC不一致 該問題需要EPC配合解決 5 當安全模式流程通過后 終端接入失敗分為兩種情況 a 基