【正文】 （包括網管、計費、公安監(jiān)聽系統(tǒng)、BOSS系統(tǒng)等等）而 IOPLAU又是由 IOC來控制。 如果 LAU板不好，肯定會影響其下帶的X25LINK不好。 首先 ，用 〈 STATSSP；查看相關設備的狀態(tài) 。 ? STATSSP。 EXEC39。D ? UNIT OST UNIT OST UNIT OST ? + + + ? BAP0 MAS BAP1 SPR CAP0 ACT ? CAP1 ACT CAP2 ACT CAP3 ACT ? CAP4 ACT CAP5 ACT CAP6 ACT ? CAP7 ACT CAP8 ACT CAP9 ACT ? IOC0 ACT IOC1 ACT CMY0 ACT ? CMY1 ACT BCMY0 ACT BCMY1 ACT ? IOPMB0 ACT IOPMB1 ACT IOPMB32 ACT ? IOPMB33 ACT IOPMB34 ACT IOPMB35 ACT ? IOPMB40 ACT IOPMB41 ACT IOPMB42 ACT ? IOPMB43 ACT IOPUNI0 ACT IOPUNI1 ACT ? IOPTA0 ACT IOPTA1 ACT IOPLAU0 ACT ? IOPLAU1 ACT IOPLAU2 ACT IOPLAU3 ACT ? LAU0 ACT LAU1 ACT LAU2 ACT ? LAU3 UNA * ? MDD0 ACT MDD1 ACT MOD0 ACT ? MOD1 ACT OMT0 ACT OMT1 ACT ? X25LINK0 ACT X25LINK1 ACT X25LINK2 PLA ? X25LINK3 UNA* X25LINK4 ACT X25LINK5 ACT ? END JOB 3314 ? 從上面結果顯示 LAU3和 X25LINK3狀態(tài)為 UNA。判斷為LAU3故障引起 X25LINK3問題。 確定 X25LINK3連接到 LAU3上的指令為： 〈 DISPIOP:IOP=IOPLAU3。 EXEC39。D IOC BIOC IOPLAU OST LAU OST CHAN0 CHAN1 LDTYP LDPRTY IOPLAUR ++++++++++ 1 15 3 ACT 3 ACT X25LINK3 100 LOW 2 END JOB 3316 ? 把 X25LINK3 人工閉鎖，然后把 LAU3閉鎖，進行診斷，沒有錯誤。依次擊活 LAU3和 X25LINK3，仍然不能恢復。 ? 再判斷是否由于上一級的故障引起。依次閉鎖 X25LINKLAU IOPLAU3。對 IOPLAU3進行診斷，也沒有發(fā)現錯誤。 ? 依次擊活 IOPLAU LAU X25LINK3，故障排除。 漫游故障處理 從投訴統(tǒng)計來看，我市漫游故障發(fā)生較多，其故障狀態(tài)一般為： （ 1）手機無法登記入網 （ 2）只能作主叫，無法作被叫 （ 3）手機無信號 對于外地手機在株洲無法登陸上網絡的情況，要檢查相關漫游局數據是否完整。要查閱相關 GT數據。手機無法登記，一般是由于位置更新失敗引起的，這時，應檢查有關 LOCUPD的 GT數據，看看是否有遺漏。 相關指令： DISPGTDEST： TRID=LOCUD,GTDIG=46000XXX。 DISPGTCPT:TRID=LOCUPD,GTDIG=46000XXX。 對于只能做主叫，不能做被叫的情況：要檢查 INTINT的 GT數據。如果 GT數據有錯誤，會造成只能做主叫，不能做被叫的情況，具體檢查方法如下： ? 對于省內情況。被叫 MSISDN號碼的 INTINT GT數據應該指向 LSTP局。 ? 對于省外用戶，被叫 MSISDN號碼的 INTINT GT數據應該指向 HSTP局。 ? 具體指令： ? 〈 DISPGTDEST： TRID=INTINT， GTDIG=8613XXXX； 如果是省內號碼， TRLG=LSTP 如果是省外號碼： TRLG=HSTP 由于各省采用的交換設備的不同，其軟件方面的差異，可能造成漫游故障。遇到這樣的問題，同廠家工程師聯系 ? 對于手機無信號的情況，應首先從無線的角度分析。 的處理 2021年 1月 7日上午 10:38:50株洲 MSC4到 BSC26的 16條信令鏈路全部阻斷，信令點不可達，導致業(yè)務障礙， 11:43:23恢復，持續(xù)時間約 5分鐘。告警記錄如下： 告警記錄如下： 發(fā)生時間 恢復時間 告警類別 位置 原因值 10:38:33 10:43:23 鏈路號 =7。 模塊號 =7。 槽位值 =21。 9 10:38:33 10:43:23 鏈路號 =8。 模塊號 =7。 槽位值 =21。 255 10:38:50 10:43:23 鏈路號 =1。 模塊號 =7。 槽位值 =21。 14 10:38:50 10:43:23 鏈路號 =3。 模塊號 =7。 槽位值 =21 14 10:38:50 10:43:23 鏈路號 =4。 模塊號 =7。 槽位值 =22。 14 10:38:50 10:43:23 鏈路號 =6。 模塊號 =7。 槽位值 =22 14 10:38:50 10:43:23 鏈路號 =28。 模塊號 =6。 槽位值 =22。 14 10:38:50 10:43:23 鏈路號 =32。 模塊號 =6。 槽位值 =21。 14 10:38:50 10:43:23 鏈路號 =36。 模塊號 =6。 槽位值 =22。 14 10:38:50 10:43:23 鏈路號 =39。 模塊號 =6。 槽位值 =21。 14 上述告警均產生于信令鏈路第二層，告警信息總的來說表明是由于信令鏈路上收不到 BSC26的消息引起，具體分析如下： 一、告警發(fā)生的同時沒有相關的中繼告警，說明信令鏈路斷不是由于傳輸原因引起。 二、 10:38:33 MSC7號模塊到 BSC26的 7,8兩條鏈路斷 , 原因值為 9（物理鏈路斷） 和 255 （未知），其中“物理鏈路斷”產生的機制是 : 信令鏈路開始定位后 , 秒沒有接收到任何消息。 三、 10:38:50 6號模塊和 7號模塊到 BSC26的另外 14條鏈路同時斷 , 原因值為 14（ T7超時），“ T7超時”產生的機制是 : 本局在鏈路上發(fā)出消息后 , 設置等待響應定時器 T7(2秒 ),如果對方超時無響應 , 則報此原因 , 鏈路中斷。 從 ZXG10MSC/VLR工作原理來看，各模塊為負荷分擔方式，到 BSC26的信令鏈路分布在 7兩個模塊共四塊信令板上，上述異常是由各信令板對每條鏈路獨立檢測出的，而兩個模塊、多塊信令板同時發(fā)生故障又同時恢復是不可能的。 綜合以上情況，技術人員認為，信令鏈路斷的問題不是由于 MSC原因產生的。 在 BSC26上檢查發(fā)現， BSC有 GCLK告警，更換 GCLK板后告警排除。 ? 2021年 12月 25日晚 18： 00分，交換機 MSC2執(zhí)行，造成 18： 00分的 。 間未釋放，造成計費堆積。 18： 45分計費文件 文件空間占用超過 15%，交換機吐 。監(jiān)控人員立即通知交換值班人員。值班人員立即趕往現場。由于當晚圣誕節(jié) CP負荷很高， 快， 19： 30分左右 39%。我們通過檢查發(fā)現，造成故障的原因主要是由于 MSC2的負荷很高，TRANSFILE的速度緩慢， 17： 45分的 件 18： 00仍未執(zhí)行完畢。使得 18： 00的文件沒有正常執(zhí)行。 20： 00，我們刪除 TMP文件，并使 TP的指針加一后執(zhí)行 ，正常， 22： 13 ? （超大文件 48M），此后 22： 15的文件正常執(zhí)行，計費恢復正常。我們同計費中心聯絡，提醒刪除重復話單，并將超大文件交帳務中心手工采集到省計費中心。 謝 謝！