無責任雜記(002)

[前言]
此部份紀錄還有待仔細驗證，目前只是自己的聽聞筆記，請勿引用。

[主題]
行動網路全網監控的困難度

日前剛聽說Tektronix的NSA Analyzer全網監控的架構目前還無法應付2個以上的RNC，感到非常驚訝，因為NSA Analyzer是我心目中剛投票給100分的儀器呢。姑且不論此說法是否為真，倒是覺得可以當作一個題目好好研究一下，因為如果Tektronix做不到，筆者不認為其他儀器可以輕鬆達成，包在裡面的石頭是一樣硬的。

其實仔細分析，可以略知這個工程的困難度的確非常高。

分析如下：一個RNC可以管理多達200個以上的NodeB，一個NodeB代表一個Iub界面，所以要完全監控一個RNC，必須同時監看與此RNC相連的所有Iub，這是RNC的前半段，後半段加上所有Iu界面。Iu界面又分成IuCS與IuPS，一般operator為了避免loading過大，會在Iu界面施行load sharing的措施，亦即將兩條STM-1當作一條Iu界面來用(無論IuCS或IuPS都有)，這樣就多出4個STM-1的port。

所以光是一個RNC的完全監控，保守估計，就包含了150個Iub的STM-1(在此假設是中等規模的UTRAN，只接了150個NodeB，而且Iub不考慮IMA架構，都是單純的STM-1)與至少四條STM-1給Iu界面使用，還有一些E1界面或Ethernet界面給HSS以及Gn, Gi等其它完整call trace的必需界面。光這些實體界面多達幾百個port還不夠驚人，這些界面平常即使沒有user traffic也不會是靜止的，其中維護用的control signal就以非常驚人的速率累積到監控系統中的硬碟。

然而就像保全的錄影一樣，由於你不知道何時會發生狀況，只好將每個角落的錄影畫面乖乖地保存起來，等幾天以後再消除，這些線路中出現的所有信令，在沒有事先妥善的理論模型保證之下，一般operator不敢漏失任何資料，都以完全紀錄的方式保存，包含每個ATM cell，每個E1的frame，每個IP的packet，都詳實記錄在raw data中。

接下來問題才大條呢，首先是保存的資料要以Tektronix自己特有的資料格式還是operator定義好的資料庫格式呢？如果以Tekrtonix自己特殊的資料格式保存，好處是raw data的檔案可以保持在最小，相同硬碟空間因此可以大量儲存資料，但是相對地，如果想看某個時刻所發生的事件詳情，必須將這些raw data以檔案名稱找出來(因為time stamp是raw data的一部分，無法從檔案外觀閱讀)，用專用軟體"倒"(playback)回去重新看一次，在倒資料的同時，利用NSA Analyzer的集成功能，重新統計分析那段時間在各界面(所有包住RNC的界面)所有信令，進而分析出事件的發生原因。

其中這個"倒"資料的過程就有很大的學問，舉例來說，假設要看某事件發生前後共3天的資料，在回顧的時候，必須將這三天的raw data整個"倒"出來，這種資料量是非常大的，光是"倒"資料就要花上數小時，要等全部"倒"到記憶體中，對這三天的統計分析與搜尋的功能才能發揮即時作用，而我懷疑目前的電腦能有如此大的記憶體來暫存如此龐大的資料量，所以很可能是倒一段資料 -> 分析一段 -> 清除記憶，再倒下一段 -> 分析下一段 -> 再清除記憶 ... 直到所有raw data都跑完為止，這種作法在實際找出網路問題之前，需要額外花費多少時間實在難以預估。

接下來談另一種方式。這種方式是raw data被固定時間儲存成大小有限的檔案，例如每10分鐘儲存一筆，然後程式自動將此raw data"倒"進NSA Analyser中，(別忘了這時前線還在繼續打仗，線上的每筆資訊依然繼續被記錄在新的raw data中)，倒入NSA Analyser的raw data，依照operator事先定義的格式，將其中重要的KPI(Key Performance Indicator)取出轉換成資料庫的資料，經過分析過濾後這筆raw data其實已經算被"看過了"，operator可以選擇繼續保存或是乾脆刪除。

這樣處理的優點是可以直接在資料庫平台上做網路效能的統計分析，不再受限於raw data的特殊格式，operator可以聘用程式高手，配合幾種移動網路效能分析理論模型，在這些從網路界面所撈出來的協定資料上大玩統計分析遊戲，雖然要等raw data被儲存以後才開始分析，不算真正的real-time，可是僅僅10分鐘或甚至是1小時的延後分析，對網路整體效能的評比絲毫沒有影響。

第二種方式看起來很優雅，但是缺點仍然有，首先是raw data經過解碼，轉換成人類可以閱讀的ASCII訊息以後，檔案大小會暴增，會有比原本raw data更佔記憶容量的轉換後檔案，塞滿資料庫。唯一節省資料庫空間的作法是先決定那些資料是垃圾，那些資料是珍珠，垃圾不留就可以大幅節省資料庫的容量，這部份有賴移動網路效能分析理論模型的建立與驗證，筆者憂心，模型恐怕永遠跟不上新應用的出現，因為每種新應用多少會改變使用者的習慣，甚至修改到PDU(Protocol Data Unit)的大小，好不容易建立的模型可能又需要修改才能有用。

第二種方式還有很大的挑戰，如前所描述，程式需要同時做好幾件事：
1. STM-1/E1/Ethernet線上資料的定期儲存(不解碼、不分析，只紀錄最底層的所有資料)
2. 將儲存的raw data資料集中送回資料庫
3. 在資料庫端將raw data以特殊程式解碼、過濾、儲存成新的資料庫格式檔案。
這些事情恐怕不容易被區區一部電腦或是架構簡單的程式所掌握。(筆者要再次提醒：本文中154條STM-1，兩條E1與兩個Ethernet的監控也僅是針對一個RNC監控的基本需求而已，如果operator有8個RNC，該如何監控呢？，如果MSC界面也需要監控，那還需要額外的STM-1 port與Ethernet，甚至Giga-Ethernet的配備，又該如何監控呢？複雜度實在很大。)

[結論]
筆者不知道目前Tektronix使用第一種或是第二種方式，也聽說NetHawk在停止probe計畫多年後，最近又開始全網監控的研發，可是無論那家公司的那種產品，相信都脫離不了本文描述的架構，也都面臨相同的困難：監控界面的多樣化與大數量，raw data的處理，以及raw data分析後的統計分析。

這已經不是使用一部電腦、幾張卡片同時在2個Iub，2個Iu界面來demo針對幾十個用戶的call trac就可以交差了事的小工程，當然，筆者承認能做到這點已經很不簡單，可是比起全網監控，還只是一本書的序言而已！

祝福全網監控的技術早日成熟。

070517r2版本