【正文】 17 需要注意的是，如果每次重發(fā)時， MSC 返回的錯誤原因不同的話，最終重發(fā)的次數(shù) 可能會超過 3 次。在此情況下，一般采用于用戶缺席相同的重試機制。此時應該立即丟棄當前短消息。此時應該立即丟棄當前短消息。 8． MS 接收錯誤：用戶手機在接收短消息過程中出現(xiàn)錯誤。 7． MS 不支持：用戶手機不支持接收短消息。 5． 網(wǎng)絡不支持：用戶當前所處的 MSC 不支持短消息。 4． 呼叫禁止：該用戶的短消息業(yè)務在 HLR 被禁止。 3． 無短消息業(yè)務：該用戶的短消息業(yè)務在 HLR 未開通。 2． 未知用戶：向 HLR要路由時， HLR 返回用戶不認識。 16 十二種失敗原因及建議采用的重發(fā)機制如下： 1． 未知錯誤： HLR/目的 MSC返回失敗，但沒有錯誤原因。 3． 隔 1 小時，重發(fā) 1 次，如失敗停止（等待 ALERTSC 消息觸發(fā)再次重發(fā)）。 缺席用戶類重發(fā)機制： 15 1． 隔 2 分鐘，發(fā) 1 次，失敗繼續(xù)下一步在此情況下，一般采用于用戶缺席相同的重試機制。 開戶用戶 GPS PROFILE， 12 種失敗原因都選擇不支持短消息重發(fā)機制（全部丟棄）。 13 8 附件一緊急維護記錄 表 1 ZXG10SC（ ）系統(tǒng)緊急維護記錄 局名 設備型號 版本 處理人 聯(lián)系電話 維護人員 開始處理故障時間 結束故障處理時間 故障現(xiàn)象及處理過程描述（要求詳盡）： 故障結論： 14 9 附件二重試配置 考慮到重發(fā)對系統(tǒng)處理能力的影響，建議對一個 MO消息最多進行 3次強制重發(fā)，對于三次重發(fā)后仍然失敗的短消息，如果未超過系統(tǒng)設置的有效期，則依靠 HLR 發(fā)來的 ALERTSC 消息觸發(fā)再次重發(fā)。 （ 2） 重新啟動業(yè)務處理機 將業(yè)務處理機重新啟動，觀察負荷或者故障現(xiàn)象是否消息 （ 3） 倒換業(yè)務處理機 將業(yè)務處理機或者后臺數(shù)據(jù)庫故障不能在短消息間內(nèi)恢復的情況下，請倒換數(shù)據(jù)庫進行業(yè)務恢復。 1） 對于 SQL 數(shù)據(jù)庫的系統(tǒng)，每個節(jié)點對應以下 3 類表： msdest， shortmsg（ 000031）， shortmsg_timing。 （ 4） 取消所有用戶的狀態(tài)報告發(fā)送要求 在節(jié)假日，為了避 免出現(xiàn)話務擁塞，在系統(tǒng)檢測到流量到達了平時流量的約 3倍時，即可以由系統(tǒng)取消對點對點發(fā)送狀態(tài)報告的取消。 12 在節(jié)日話務高峰過后，直接將備份的數(shù)據(jù)倒換回備份的配置即可恢復正常的運行。 執(zhí)行方法是在短消息 SC配置管理中，首先備份當前的系統(tǒng)配置，然后在 RSM中增加一種重試方式（假定為 10），該重試方式為間隔 1秒重試 0次，結束動作為丟棄。 在節(jié)日高峰完成后直接恢復回備份配置即可。 在全用戶廣播、大客戶終端、催繳費等應用程序中停止或者取消消息的發(fā)送，將消息的任務時間定義在節(jié)日高峰流量之后。對于各種垃圾數(shù)據(jù)和可能影響系統(tǒng)運行效率的數(shù)據(jù)考慮進行清理。 節(jié)假日短信業(yè)務的另一個特點是，點對點發(fā)送成功率要求高， ESME 發(fā)送可靠性相對較低。 11 7 節(jié)日應急處理 由于短消息在節(jié)假日具有爆發(fā)性的特點，因此擬訂節(jié)日應急流程。 ******** Interrupt Task Many Run ******** Date: 20201227 11:17:44 Module: 2 Position: Right(Down) State: Slave UB: 2996, 999, 400, 398, 400, 397, 272, 37 CPU: 66 Task Name: ne2Rece Phase Name: 0 Phase Depeth: 255 Last Run Count: 1233668 上次運行記錄 Current Run Count: 1301627 當前運行記錄 網(wǎng)絡風暴應急處理 網(wǎng)絡風暴出現(xiàn)時，視對系統(tǒng)的影響程序進行處理，如果影響系統(tǒng)的基本業(yè)務，請斷開短消息中心和所有外接實體之間的物理連接，然后逐步將外部實體接入到短消息中心，觀察 5 分鐘以上后無誤后，再進行后面實體的連接，以查找故障源頭。 前臺日志分析：在網(wǎng)絡風暴出現(xiàn)時，前臺交換機會將收到的網(wǎng)絡包（以太）的數(shù)量記錄，請將 MP 日志導出分析。對于短消息中心的前臺交換機和業(yè)務處理機等設備運行的主要功能實體，可能出現(xiàn)程序保護的反復重新啟動現(xiàn)象。因此網(wǎng)絡干擾可能發(fā)生。 如果修改配置后引起業(yè)務中斷，請將配置恢復到維護操作之前的配置，然后執(zhí)行數(shù)據(jù)的同步。 6． 如果發(fā)現(xiàn)短消息中心資源不夠，進行上述處理后如果還不能解決，就重啟短消息 中心業(yè)務處理機系統(tǒng)，如問題仍然存在，請與 ZXG10SC 技術人員聯(lián)系。 （ 6） 取消因缺席原因（含關機和不在服務區(qū)）引起的重發(fā)設置，將結束動作由停止改為丟棄。 （ 4） 取消因系統(tǒng)錯誤引起的重發(fā)設置。 （ 2） 通知各 SME（如網(wǎng)關等），進行流量限制。 4． 如果發(fā)現(xiàn)數(shù)據(jù)庫、話單文件等的資源不夠，譬如分配的硬盤空間已經(jīng)耗盡的情況，可以將系統(tǒng)中早期的數(shù)據(jù)庫歷史表、話單文件等備份到其他的機器上，騰出硬盤空間。 2． 不要使用性能統(tǒng)計中的實時觀察、信令跟蹤、探針、系統(tǒng)監(jiān)測、業(yè)務觀察等。如果再加上適當?shù)娜斯ふ{(diào)節(jié)，將使短信系統(tǒng)運行更加穩(wěn)定可靠，使有限的業(yè)務處理能力得到更加 9 合理的利用。這主要是通過對短信系統(tǒng)的安全變量的參數(shù)進行設置實現(xiàn)。 4． 針對各個局所開展的不同的短消息業(yè)務，進行相