電子發燒友App
1、引 言
通信網絡測試儀中的信令分析，針對的是協議棧一系列的傳輸層和應用層協議。儀表協議分析的基礎，要能夠實現對所接收到的網絡數據進行譯碼解析，并在此功能上進行更高級的統計追蹤功能。在進行協議分析時，鑒于協議之間消息格式和處理機制的不同，以及軟件模塊化的實現要求，采取以單個協議進行模塊封裝的辦法是更有效的，其好處在于能夠忽略協議問功能和格式的細微差別，對單個協議的分析方法也能在很大程度上推廣到其他協議。
本文研究的主要內容是CAP消息的分析，一方面描述如何根據協議標準中規定的協議消息結構進行解碼，另一方面結合實際情況探討CAP消息的統計及呼叫數據記錄合成等功能。
2、CAP協議概述
智能網是通信技術和計算機技術相融合的經典范例，其基本思想是將業務控制智能從交換網絡中分離出來，以No.7信令系統為橋梁，使交換網絡的控制信息與大容量分布式數據庫聯系起來，集中控制，以方便新業務的引入和快速適應不斷變化的市場需求，不必像過去那樣在大范圍多機種的交換機上進行繁雜的修改。
為了在移動通信系統中引入智能網，歐洲電信標準研究所（ETSI）于1997年在GSM Phase 2+上定義了CAM-EL（Customised Applications for Mobile network EnhancedLogic，移動網絡增強邏輯的客戶化應用協議）。CAMEL協議的特征是為用戶提供一種網絡無關的業務一致性。即使用戶不在其所歸屬的公共陸地移動網絡（HPLMN）中CAMEL協議也可以作為一種手段幫助網絡運營者向用戶提供特定的業務。CAP（CAMEI，Application Part）是CAMEL的應用部分，他基于智能網的INAP協議。CAP協議描述了移動智能網中各個功能實體之間的標準
通信規程。
CAP作為應用層協議，與INAP，MAP同屬于TCAP的用戶，他們在七號信令系統中的位置如圖1所示。
移動智能網系統中的各個設備往往是各個不同的廠家提供的，CAP定義的精確和無二義性就變得非常重要。目前CAP的語法的定義使用ASN.1。
ASN.1（Abstract Syntax NotationOne）就相當于描述傳送語法的一種語言，他定義的編碼規則也就是從不同的協議語言到統一的傳送語法之間的轉換規則。因此，在具體實現時，必須在發送方設置一個ASN.1編碼器，將發送方所要傳送的符合發送方編程語法的消息格式轉換成為符合ASN.1編碼規則的格式然后再發送出去，然后在接收方設置一個ASN.1解碼器，將接收到的符合ASN.1編碼規則的消息格式解碼為符合接收方協議語法的消息格式。這樣，經ASN.1描述的信息獨立于任何應用系統及傳送網絡，不會因為應用環境的不同而引起二義性的解釋。
ISO在制定ASN.1的同時也推出了ASN.1的兩種編碼規則，一是基本編碼規則（Basic Encode Rule，BER），詳細內容請見X.690；另一個是數據包編碼規則（Packet EncodeRule，PER），詳細內容請見X.691。BER和PER實際上都是一種傳送語法，他可以把復雜的用抽象語法描述的數據結構表示成簡單的數據流，從而便于在通信線路上傳送。PER就是在BER的基礎上，以減少編碼開銷為目的而設計的編碼規則，相對BER編碼更加精簡，但目前的通信協議仍以BER編碼居多，CAP協議遵循BER編碼規則［4］。
3、 CAP軟件模塊系統設計
3.1 CAP軟件模塊的設計要求
對于通信網絡測試儀器的軟件模塊，CAP模塊需要滿足CAP消息的詳細解碼，信息提取、統計，CDR合成，過濾等功能。其設計主要考慮以下方面：
（1）軟件的面向對象及模塊化設計
在面向對象思想下采用模塊化設計，模塊內部的結構清晰易懂，各模塊之間相對獨立。這樣便于檢查錯誤，節省開發時間，提高了軟件系統的穩定性、可修改性和重用性。
（2）與數據庫的配合
通信測試系統涉及到數量相當大的數據庫文件系統，信息提取，消息統計及CDR合成均需要同數據庫配合，因此，在軟件模塊設計期間要考慮模塊的數據庫實現問題。
（3）模塊的效率問題
為滿足測試儀表長時間大負荷監控和實時解碼統計等功能，模塊必須提高運行效率。為了更好地提高軟件的性能，在軟件設計上，可以考慮采取多線程，流水線技術。
3.2 CAP模塊的結構分析
系統分析在用戶需求的基礎上，采用面向對象的思想對CAP模塊具體分析，劃分系統的各個部分，明確他們之間的層次關系，然后將各個部分作為一個對象進行功能分析，對每一層次的數據進行加工處理，并向上一層提供必要的支持。根據軟件總體架構方案協議消息處理流程如圖2所示。
其中，采集卡捕獲到的數據首先保存在消息緩存中；解碼器從消息緩存中取出消息逐條進行粗略解碼，獲得每幀數據的幀信息和呼叫信息；這兩類信息按照協議類別交給呼叫合成器進行呼叫合成，得到每個協議的CDR集合，保存在CDR緩存中；根據用戶需要進行顯示和統計。統計功能可以直接面向CDR緩存進行，也可以先將CDR輸入數據庫，在數據庫中進行統計，然后輸出統計結果。對于CAP模塊，我們主要實現CAP解碼器和呼叫合成器的
設計與實現。
3.3 CAP軟件模塊研究與實現
3.3.1 CAP協議解碼分析
在對CAP進行解碼分析前，首先要知道BER編碼的基本編碼格式。BER以8 b為一個基本傳送單位。對于每個所傳送的值，無論是基本類型還是構造類型，都由TLV三個字段組成。TLV分別指標識類型標識符域（TAG）、數據長度域（LENGTH）和數據域（VALUE）字段。其中，數據域可以多重嵌套其他數據元素的TLV字段。BER編碼的具體格式如圖3所示。
在CAP協議描述中，以localValue，length，operator-code，errorcode分別對應BER編碼中的TLV，組成樹狀數據結構圖［1］，具體解碼設計將在下面分析。
3.3.2 解碼器實現方案
在通信測試儀表中主要是對協議及信令的PDU進行操作，為滿足對PDU的公共操作我們制定了CPdu基類，主要實現對PDU的創建、刪除、合并、內存管理、長度檢查、指針操作等基本功能。在繼承CPdu類的基礎上，我們派生出CPduCap類，在類CPduCap中設定外部接口函數int Deeode（CString&res），完成詳細解碼過程，并通過引用傳遞的方式將解碼結果置于CString類型的字符串內，便于主控方調用解碼結果。返回值結果定義如下：1：非本層PDU，不操作res；0：成功解碼；1：本層PDU，解碼出錯，錯誤信息加到結果字符串中。
由于ASN.1語法的特點，Decode（CString＆res）函數采用樹狀遍歷嵌套調用的方式進行解碼，直至解到BER的基礎函數為止。
在基礎解碼函數中，我們大量使用C++標準模板庫中的模板類：容器std：：vector。vector是一個多功能的，能夠操作多種數據結構和算法的模板類和函數庫，在ASN．1復雜數據機構的環境下，vector的使用方便了對各種數據類型進行讀取、存儲、轉換操作。
詳細解碼的實現是對通信協議進行深層次分析，以及統計、CDR合成的基礎，下面主要關注CAP CDR合成的實現。
3.3.3 呼叫合成器實現方案
呼叫合成器的主要功能就是根據到達的幀信息和呼叫信息，將幀消息按呼叫歸類，即把消息ID加入到相應的CDR記錄中，并在呼叫結束時通知CDR緩存。CDR（calldata record）在PSTN中表示呼叫數據記錄，現在延伸意思為一個完整的流程，CDR合成是上述功能的基礎，對網絡中消息按信令流程進行歸類，并用索引方式把這些消息聯系到一起，然后才便于完成諸如呼叫跟蹤和呼損統計等高級功能。CDR合成算法主要是根據一些關鍵參數進行查找、匹配來確定是否屬于同一個消息流程，因此在這個過程中，需要一些臨時存儲方式來保存沒有匹配到的消息，在內存分配上比較復雜，涉及動態分配內存。
移動智能網應用部分（CAP）是在7號信令的SCCP/TCAP之上的，即CAP為TCAP的用戶（也稱TC用戶），直接與TCAP的成分子層相連。CAP使用TCAP所提供的TC請求原語將要發送的CAP消息傳送至TCAP成分子層，然后再通過TCAP的事物處理子層、SCCP以及MTP將消息發到對端，或者使用TCAP所提供的指示原語接收對端發來的CAP消息。
TCAP有兩個重要概念：對話和操作。在網絡中一對節點之間使用TCAP進行的所有通信都被結構化為對話。例如，為處理一個智能呼叫而在SSP和SCP之間進行的所有通信可構成一個對話。在對話過程中交換的信息元素稱為操作，CAP協議的消息即存放在這些信息元素中傳輸。操作由源TC用戶調用，請求目的地TC用戶執行該操作指定的動作。在這個過程中，每個成份處理TC原語均帶有一個事務ID（也稱對話ID），成份子層收到此原語后，就將收到的對話ID與其相同的所有成份分配給這一對話。因此，我們在CAP的CDR過程中，以Transac-tionID作為關鍵字CDR ID在數據結構中進行查找，匹配，確定惟一的CDR流程。TransactionID又分源事務ID和目的事務ID，分別存在于不同的TC原語中。
在呼叫合成實現中，最主要有兩個方法：
（1）設定CDR緩存的方法void SetCdrBuffer（CAPCDR BUF*pBuf）：其中CAP CDR BUF是包含CCapCDR的CDR緩存模板類，此函數指定了CDR記錄緩存的位置。
（2）CDR處理函數：void Handle（const CallInfoCap&CapInfo，const NgnPktInfo＆ PktInfo）。他是進行呼叫合成的核心，也是設計的關鍵。他有兩個參數，分別是該協議呼叫信息和數據幀信息。其基本流程如圖4所示。
其中，判斷某CDR是否已緩存，通知CDR緩存該CDR已結束和向緩存中添加新的CDR都需要調用CDR緩存模板類的方法，對于CAP協議的CDR子類：CCapCDR，聲明一個CAP CDR緩存類型方法如下：ty-pedef CCallBufCAP CDR BUF。
在緩存操作中的具體實現如下：
（1）查詢某CDR是否已緩存，利用CDR緩存的Search方法：
newCdr.nLinkID=nLinkld：
//設定關聯屬性（根據協議類型增加）
_tcscpy（newCdr.Call ID，Caplnfo.Call ID）；
CCapCDR*pFind=m pCdrBuf=-》Search（newCdr）;
//查詢該CDR是否已存在
（2）向緩存中添加新的CDR：使用InsertNewCDR方法：
CCapCDR*pFind=m pCdrBuf-》InsertNewCDR（newCdr）；
（3）通知緩存某CDR已結束：
bool bReturn=m pCdrlBuf-》CallCompleted（*pFind）；CDR呼叫其他相關分析在此不再贅述。
4、 軟件運行實現結果
在模塊的整個開發流程中，每一步都要進行軟件的測試工作，以保證整個模塊開發工作的正確性。下面是軟件實測后進行CDR合成的結果，可以從圖5中看到，軟件實現了CAP的CDR功能，點擊單條消息名稱可以看到消息的關鍵數據，在此不再進行演示。
5、結 語
采用面向對象的思想，通過C++語言，我們實現了CAP軟件模塊。在模塊開發流程結束后，通過現場測試，該軟件模塊完全符合中國移動《軟交換測試儀表測試規范（征求稿）》中對移動智能網測試的要求，目前該軟件模塊已運用于商用通信測試儀表中。
責任編輯：gt
工商網監
評論