基于來電提醒業(yè)務實現網絡黑洞實時監(jiān)控的研究

1、中國移動集團重點中國移動集團重點/ /聯合研發(fā)項目聯合研發(fā)項目 結題匯報報告結題匯報報告 20102010年年1010月月2828日日 項目名稱：基于來電提醒業(yè)務實現網絡黑洞實時監(jiān)控的研究項目名稱：基于來電提醒業(yè)務實現網絡黑洞實時監(jiān)控的研究 項目編號：項目編號：2010_jz_15 第2頁 開題計劃完成情況開題計劃完成情況 目目 錄錄 二、主要研究成果二、主要研究成果 第3頁 1.1 1.1 研究背景及目標研究背景及目標 n研究背景 移動通信網絡中一些具有隱弊性、隨機性、個性特征的故障（網絡 黑洞），是目前網絡質量監(jiān)控工作中存在的主要難點。 現有網絡質量監(jiān)控的缺點： 一 主動性差：分析的來源依

2、賴于設備的統(tǒng)計報表、定期路測和用戶投 訴的反饋。 二 實地撥測可模擬性差：不能百分百的模擬出網絡黑洞事件。 三 定位性差：網絡信息量大，網絡黑洞容易被淹沒在海量信息中，無 法準確定位問題。 本科研項目主要針對目前主動性差、可模擬性差和定位性差的缺點， 著重于在現有信令采集系統(tǒng)設備的基礎上，建立適合主動檢測網絡黑洞， 提高網絡質量、提高維護效率的系統(tǒng)。 第4頁 n研究思路 我司提供的“來電提醒”業(yè)務是指當用戶關機、不在服務區(qū)或其它 原因導致無法接聽電話的時候，將用戶失去服務時段內的來電信息（主 叫號碼、撥叫時間等）將以短信方式發(fā)送給已處于正常狀態(tài)下的用戶， 以便用戶獲知信息并選擇是否回電。 u

3、來電提醒業(yè)務的觸發(fā)分析 p 當來電發(fā)生時，被叫當前事件為主叫忙，msc發(fā)起忙轉至來電提醒 平臺。 p 當來電發(fā)生時，被叫當前事件中在assignment complete之前出 現失敗（接入階段），msc即發(fā)起不可及轉至來電提醒平臺；在 assignment complete之后，未出現connect（呼叫建立階段）， msc即發(fā)起無應答轉至來電提醒平臺。 1.1 1.1 研究背景及目標研究背景及目標 第5頁 u來電提醒業(yè)務客戶群分析（以上海公司為例） p 現網使用來電提醒業(yè)務的用戶數為202萬，全網用戶1800萬左右，平 均為九分之一； p 使用來電提醒的客戶群大多為話務較多且可能網絡質量較

4、差，擔心失 去重要的業(yè)務信息； 由此啟發(fā)，我們發(fā)現“來電提醒”業(yè)務在無形中成為網絡微觀狀 態(tài)“監(jiān)視器”，監(jiān)控用戶在收到“來電提醒”短信之前的網絡動作， 分析正常情況下用戶為何失去服務，對隱藏在海量信息中的網絡黑 洞進行聚焦，從而可以找出問題，解決問題。 1.1 1.1 研究背景及目標研究背景及目標 第6頁 n研究目標 通過信令采集方式對來電提醒業(yè)務使用情況進行分析，歸納業(yè)務觸 發(fā)條件、使用頻次、多發(fā)區(qū)域等主要特征。通過核心側、無線側消息的 關聯分析，獲取用戶所經歷的網絡事件，并結合參數原因值探討其觸發(fā) 因素。在此基礎上，研究整理各種場景下的典型模型及相關解決措施， 并在現網試點應用。 1.1

5、1.1 研究背景及目標研究背景及目標 第7頁 1對當前“來電提醒”業(yè)務的實現從網絡層面上進行深入研究和分析。 對現有業(yè)務進行深入剖析，研究網絡側各種用戶失去服務的信令流 程，研究統(tǒng)計用戶使用“來電提醒”業(yè)務的數量與區(qū)域特征。研究無 線側各異常流程、具體參數含義與觸發(fā)條件，最終分析出信令各個流 程中的關鍵索引點。 2通過軟件分析，對用戶一段時間內的信令消息進行關聯分析，取得用 戶之前的網絡動作，研究造成該動作的原因。 選擇試點端局，跟蹤a接口信令，通過大容量信令儀表的數據收集， 應用一些軟件工作，選出信令各個流程的關鍵索引關聯出一個完整的 流程，再向上追溯前一次用戶失去服務時的信令流程，找出問題

6、癥結 點，確定是否網絡缺陷或者是黑洞。 1.2 1.2 主要研究內容及分工主要研究內容及分工 第8頁 3模型整理、現網應用、舉例分析、優(yōu)化其實用性 針對問題癥結點，通過測試和分析研究整理出各種場景的模型。聯 合其它部門一起研討具體實現方法，將篩選網絡黑洞的模型應用在現 網中。根據結果結合長效運行和管理的可行度綜合評估其實用性。例 舉采用該方法得到的案例，分析其問題或故障的形成原因，提出合理 措施，改善服務質量，提高網絡質量。最終提出采用該方法的長效質 量評估標準。 4回顧整個研究成果，評估其價值所在和推廣性。 1.2 1.2 主要研究內容及分工主要研究內容及分工 第9頁 1.3 1.3 開題計

7、劃完成情況總結開題計劃完成情況總結 以“來電提醒”業(yè)務實現網絡黑洞實時監(jiān)控方案，可以在用戶來電提 醒短信發(fā)送成功后，作為一個線索去關聯用戶前一個網絡動作，能高效的 協助網絡監(jiān)控，及時發(fā)現問題，其主要體現在： 1. 提供了網絡監(jiān)控的主動性，不再被動依賴于設備的統(tǒng)計報表、定期路測和用 戶投訴的反饋； 2. 解決了實地撥測可模擬性差問題，來電提醒業(yè)務的使用者無形中為我們提供 了實地撥測； 3. 改善了隱性問題定位的困難，通過輔助分析系統(tǒng)，能聚焦淹沒在海量信息中 的網絡黑洞，為維護人員準確定位問題提供有力的幫助； 4. 輔助分析系統(tǒng)可以大大減少值維人員的工作量，根據規(guī)則的調整可以自動獲 得初步的分析結

8、果； 第10頁 1.3 1.3 開題計劃完成情況總結開題計劃完成情況總結 當然，這種方式也存在著一些不足，即受制于信令采集點部署單 一和信令文件大小這些環(huán)節(jié)，信令文件太大影響系統(tǒng)運行的實時性， 信令文件太小則影響全面性，建議選取重點網元和重點時段展開普查， 充分發(fā)揮優(yōu)勢。 利用和挖掘“來電提醒”的這一監(jiān)控方式，今后結合信令采集平臺去 完善全網監(jiān)控，實行“發(fā)現、解決、驗證、鞏固”的長效評估模式， 對提高網絡質量，特別是端到端的用戶感知度，有著實際意義。 第11頁 一一. . 開題計劃完成情況開題計劃完成情況 目目 錄錄 二、主要研究成果二、主要研究成果 第12頁 2.1 2.1 設計思路設計思路

9、 n 設計主體思路 p 采集a口信令 p 對所有短信內容進行關鍵字過濾 （關鍵字：上海移動來電提醒為您服務） p 建立數據庫 p 提取該短信中短信中心記錄時間scts字 段（shortmessage central time stamp ） p 以scts為基準，查找信令文件中相應時 間段內被叫行為事件（分析該事件的具 體原因，并進行分類統(tǒng)計） 第13頁 2.2 2.2 系統(tǒng)架構系統(tǒng)架構 n 開發(fā)平臺 p mysql 數據庫 p microsoft visual studio 2008 n 系統(tǒng)架構 p mysql：數據庫 p mysql connector net： 基于.net平臺的數據庫

10、驅動模塊 p ado.net：數據訪問服務模塊 p dundas：圖表繪制模塊 p microsoft.office.interop.excel： excel表處理模塊 第14頁 2.3 2.3 流程設計流程設計 第15頁 2.4 2.4 數據庫建立數據庫建立 n 預分析 p 根據電路域業(yè)務控制流程，對信令文件進行解析，將每個用戶使用的業(yè) 務逐條按照預先定義的字段存入數據表a： 被叫短信事件smsmt_gsm13 主叫短信事件smsmo_gsm12 被叫paging response后未完成呼叫pagres_gsm11 被叫paging無響應paging_gsm10 被叫事件mtc_gsm9

11、主叫事件moc_gsm8 周期性位置更新lureq_gsm_p7 入局位置更新lureq_gsm_n6 開機位置更新lureq_gsm_a5 關機事件imdetin_gsm4 切換事件horeq_gsm3 主叫發(fā)起cm reestablishment request被拒絕cruser_gsm2 主叫發(fā)起cm service request被拒絕cmsreq_gsm1 事件描述事件名序號 第16頁 2.4 2.4 數據庫建立數據庫建立 n 預分析 p 掃描所有的短信事件，過濾內容中前幾個字符包為“上海移動來電提醒 為您服務”的短信，提取key鍵（frame）和短信中心時間戳（scts）、 ims

12、i、tmsi等字段，存入數據表b： 第17頁 2.4 2.4 數據庫建立數據庫建立 n 預分析 p 根據數據表b中scts字段所提供的時間戳，查詢數據表a中該時間戳附近 的用戶行為事件（imsi或者tmsi相同），查到后合并記錄存入數據表c； p 由于位置更新事件會造成用戶tmsi改變，因此如果查到的是成功的位置 更新事件，則提取該事件中old tmsi字段，繼續(xù)向前查找，查到后合并 記錄存入數據表c； 第18頁 2.5 2.5 輔助分析系統(tǒng)輔助分析系統(tǒng) n 激活來電提醒事件預分析模塊 p 用戶忙模塊被叫用戶正處于業(yè) 務使用中 p 用戶位置更新模塊被叫用戶剛 完成局間位置更新、開機位置更新 狀

13、態(tài) p 不完整流程模塊被叫響應尋呼 后未響應鑒權請求 p 用戶關機用戶已正常關機 p 尋呼無響應被叫未響應尋呼 p 觸發(fā)事件不在本信令文件中未 找到上次事件和下發(fā)的短信中記錄 的時間不在信令文件中，這部分數 據將丟棄，無利用價值； 第19頁 2.6 2.6 應用演示應用演示 n應用演示主界面信息 從一小時的信令中，共提取到3845次內容為來電提醒的短信事件， 以來電提醒短信為事件起點，對用戶的上次行為事件進行初步分類： 選中“用戶忙”，點擊詳細信息按鈕進入分析模塊 第20頁 2.6 2.6 應用演示應用演示 n 應用演示應用演示用戶忙分析模塊用戶忙分析模塊 第21頁 2.6 2.6 應用演示應

14、用演示 n 用戶忙分析演示（1）主叫行為中鑒權請求未下發(fā) p 選中“authentication request”，點擊詳細信息按鈕進入分析子模塊 其中有18次是msc以“cm reject”消息拒絕主叫（拒絕的原因為 “msg not compatible with the proto”） 第22頁 2.6 2.6 應用演示應用演示 n 用戶忙分析演示（1）主叫行為中鑒權請求未下發(fā) 點擊詳細信令按鈕，調取原始信令，分析原因 p 主被叫同時發(fā)生； - patch-ipa21 p clreq消息time大于 msc所有time，造成 msc不釋放資源； p 位置更新未完成， msc不接受其他業(yè)務

15、 請求 規(guī)范timer 第23頁 2.6 2.6 應用演示應用演示 n 用戶忙分析演示（2）被叫行為中鑒權請求未觸發(fā) p 被叫側4次鑒權流程未觸發(fā) 第24頁 2.6 2.6 應用演示應用演示 n 用戶忙分析演示（2）被叫行為中鑒權請求未觸發(fā) p 選中被叫側“authentication request”，點擊詳細信息按鈕進入分析子 模塊 第25頁 2.6 2.6 應用演示應用演示 n 用戶忙分析演示（2）被叫行為中鑒權請求未下發(fā) p 鑒權流程工作模式 首先在mm的系統(tǒng)參數中里有auth freq這個針對全局用戶的全局參數。 其次在每個用戶vlr中還有authentication count，這

16、個動態(tài)計數器參 數，是每個用戶獨立的，不會相互影響。 authenticationcount =0 執(zhí)行鑒權執(zhí)行鑒權 鑒權、加密流程正常結束鑒權、加密流程正常結束 后，修改后，修改 authenticationcount =authfreq 第26頁 2.6 2.6 應用演示應用演示 n 用戶忙分析演示（2）被叫行為中鑒權請求未觸發(fā) p 信令流程回放 第27頁 2.6 2.6 應用演示應用演示 n 用戶忙分析演示（2）被叫行為中鑒權請求未下發(fā) p 信令流程回放 主叫異常終止主叫異常終止 流程，導致未流程，導致未 能觸發(fā)修改能觸發(fā)修改 auth_count 第28頁 2.6 2.6 應用演示應用

17、演示 n 用戶忙分析演示（2）被叫行為中鑒權請求未下發(fā) p 鑒權保護機制缺陷 錯誤的判斷錯誤的判斷 機制機制 第29頁 2.7 2.7 應用小結應用小結 序號網絡黑洞關鍵字黑洞現象描述黑洞原因定位 黑洞 特征 建議 方案 1 msg not compatible with the protocol 主叫cmreq被拒 絕，無錄音通知提 示 主被叫同時發(fā)生；clreq 的定時器小于msc的所有 定時器；位置更新未完成； 隱性 廠商 優(yōu)化 2 未下發(fā) assignment request分配tch 主叫被釋放，無錄 音通知提示 啟用了預呼功能，未 paging到用戶在map層回 復“system

18、failure” 隱性 關閉 功能 3 assignment failure 被叫無法建立突發(fā)話務集中區(qū)域隨機 無線 優(yōu)化 4重復位置更新 平均每分鐘2次以 上位置更新 sim卡合法性問題；業(yè)務權 限問題；終端問題 隱性 客服 輔導 5未發(fā)起鑒權流程 被叫流程建立中未 發(fā)起鑒權流程，仍 能完成通話 設備數據庫缺陷，用戶鑒 權標志位保護機制不完善 隱性 廠商 升版 n 網絡黑洞的挖掘 鑒于這種方式具有獨特的創(chuàng)新性，項目小組已提交專利申請鑒于這種方式具有獨特的創(chuàng)新性，項目小組已提交專利申請 第30頁 2.7 2.7 應用小結應用小結 n 推廣設想與全網性的信令平臺相結合 n 設想一設想一 信令平臺開放數據庫，提供滿足輔助分析的數據信令平臺開放數據庫，提供滿足輔助分析的數據； 主要利用信令平臺全網采集的優(yōu)勢，發(fā)