通信網(wǎng)絡(luò )測試儀表中CAP軟件模塊的研究

1 引 言

通信網(wǎng)絡(luò )測試儀中的信令分析，針對的是協(xié)議棧一系列的傳輸層和應用層協(xié)議。儀表協(xié)議分析的基礎，要能夠實(shí)現對所接收到的網(wǎng)絡(luò )數據進(jìn)行譯碼解析，并在此功能上進(jìn)行更高級的統計追蹤功能。在進(jìn)行協(xié)議分析時(shí)，鑒于協(xié)議之間消息格式和處理機制的不同，以及軟件模塊化的實(shí)現要求，采取以單個(gè)協(xié)議進(jìn)行模塊封裝的辦法是更有效的，其好處在于能夠忽略協(xié)議問(wèn)功能和格式的細微差別，對單個(gè)協(xié)議的分析方法也能在很大程度上推廣到其他協(xié)議。

本文研究的主要內容是CAP消息的分析，一方面描述如何根據協(xié)議標準中規定的協(xié)議消息結構進(jìn)行解碼，另一方面結合實(shí)際情況探討CAP消息的統計及呼叫數據記錄合成等功能。

2 CAP協(xié)議概述

智能網(wǎng)是通信技術(shù)和計算機技術(shù)相融合的經(jīng)典范例，其基本思想是將業(yè)務(wù)控制智能從交換網(wǎng)絡(luò )中分離出來(lái)，以No.7信令系統為橋梁，使交換網(wǎng)絡(luò )的控制信息與大容量分布式數據庫聯(lián)系起來(lái)，集中控制，以方便新業(yè)務(wù)的引入和快速適應不斷變化的市場(chǎng)需求，不必像過(guò)去那樣在大范圍多機種的交換機上進(jìn)行繁雜的修改。

為了在移動(dòng)通信系統中引入智能網(wǎng)，歐洲電信標準研究所(ETSI)于1997年在GSM Phase 2+上定義了CAM-EL(Customised Applications for Mobile network EnhancedLogic，移動(dòng)網(wǎng)絡(luò )增強邏輯的客戶(hù)化應用協(xié)議)。CAMEL協(xié)議的特征是為用戶(hù)提供一種網(wǎng)絡(luò )無(wú)關(guān)的業(yè)務(wù)一致性。即使用戶(hù)不在其所歸屬的公共陸地移動(dòng)網(wǎng)絡(luò )(HPLMN)中CAMEL協(xié)議也可以作為一種手段幫助網(wǎng)絡(luò )運營(yíng)者向用戶(hù)提供特定的業(yè)務(wù)。CAP(CAMEI，Application Part)是CAMEL的應用部分，他基于智能網(wǎng)的INAP協(xié)議。CAP協(xié)議描述了移動(dòng)智能網(wǎng)中各個(gè)功能實(shí)體之間的標準
通信規程[1,2]。

CAP作為應用層協(xié)議，與INAP，MAP同屬于TCAP的用戶(hù)[3]，他們在七號信令系統中的位置如圖1所示。


 


移動(dòng)智能網(wǎng)系統中的各個(gè)設備往往是各個(gè)不同的廠(chǎng)家提供的，CAP定義的精確和無(wú)二義性就變得非常重要。目前CAP的語(yǔ)法的定義使用ASN.1。

ASN.1(Abstract Syntax NotationOne)就相當于描述傳送語(yǔ)法的一種語(yǔ)言，他定義的編碼規則也就是從不同的協(xié)議語(yǔ)言到統一的傳送語(yǔ)法之間的轉換規則。因此，在具體實(shí)現時(shí)，必須在發(fā)送方設置一個(gè)ASN.1編碼器，將發(fā)送方所要傳送的符合發(fā)送方編程語(yǔ)法的消息格式轉換成為符合ASN.1編碼規則的格式然后再發(fā)送出去，然后在接收方設置一個(gè)ASN.1解碼器，將接收到的符合ASN.1編碼規則的消息格式解碼為符合接收方協(xié)議語(yǔ)法的消息格式。這樣，經(jīng)ASN.1描述的信息獨立于任何應用系統及傳送網(wǎng)絡(luò )，不會(huì )因為應用環(huán)境的不同而引起二義性的解釋。 

ISO在制定ASN.1的同時(shí)也推出了ASN.1的兩種編碼規則，一是基本編碼規則(Basic Encode Rule，BER)，詳細內容請見(jiàn)X.690；另一個(gè)是數據包編碼規則(Packet EncodeRule，PER)，詳細內容請見(jiàn)X.691。BER和PER實(shí)際上都是一種傳送語(yǔ)法，他可以把復雜的用抽象語(yǔ)法描述的數據結構表示成簡(jiǎn)單的數據流，從而便于在通信線(xiàn)路上傳送。PER就是在BER的基礎上，以減少編碼開(kāi)銷(xiāo)為目的而設計的編碼規則，相對BER編碼更加精簡(jiǎn)，但目前的通信協(xié)議仍以BER編碼居多，CAP協(xié)議遵循BER編碼規則[4]。

3 CAP軟件模塊系統設計

3.1 CAP軟件模塊的設計要求

對于通信網(wǎng)絡(luò )測試儀器的軟件模塊，CAP模塊需要滿(mǎn)足CAP消息的詳細解碼，信息提取、統計，CDR合成，過(guò)濾等功能。其設計主要考慮以下方面：

(1)軟件的面向對象及模塊化設計

在面向對象思想下采用模塊化設計，模塊內部的結構清晰易懂，各模塊之間相對獨立。這樣便于檢查錯誤，節省開(kāi)發(fā)時(shí)間，提高了軟件系統的穩定性、可修改性和重用性。

(2)與數據庫的配合

通信測試系統涉及到數量相當大的數據庫文件系統，信息提取，消息統計及CDR合成均需要同數據庫配合，因此，在軟件模塊設計期間要考慮模塊的數據庫實(shí)現問(wèn)題。

(3)模塊的效率問(wèn)題

為滿(mǎn)足測試儀表長(cháng)時(shí)間大負荷監控和實(shí)時(shí)解碼統計等功能，模塊必須提高運行效率。為了更好地提高軟件的性能，在軟件設計上，可以考慮采取多線(xiàn)程，流水線(xiàn)技術(shù)。

3.2 CAP模塊的結構分析

系統分析在用戶(hù)需求的基礎上，采用面向對象的思想對CAP模塊具體分析，劃分系統的各個(gè)部分，明確他們之間的層次關(guān)系，然后將各個(gè)部分作為一個(gè)對象進(jìn)行功能分析，對每一層次的數據進(jìn)行加工處理，并向上一層提供必要的支持。根據軟件總體架構方案協(xié)議消息處理流程如圖2所示。 


 

其中，采集卡捕獲到的數據首先保存在消息緩存中；解碼器從消息緩存中取出消息逐條進(jìn)行粗略解碼，獲得每幀數據的幀信息和呼叫信息；這兩類(lèi)信息按照協(xié)議類(lèi)別交給呼叫合成器進(jìn)行呼叫合成，得到每個(gè)協(xié)議的CDR集合，保存在CDR緩存中；根據用戶(hù)需要進(jìn)行顯示和統計。統計功能可以直接面向CDR緩存進(jìn)行，也可以先將CDR輸入數據庫，在數據庫中進(jìn)行統計，然后輸出統計結果。對于CAP模塊，我們主要實(shí)現CAP解碼器和呼叫合成器的
設計與實(shí)現。

3.3 CAP軟件模塊研究與實(shí)現

3.3.1 CAP協(xié)議解碼分析

在對CAP進(jìn)行解碼分析前，首先要知道BER編碼的基本編碼格式。BER以8 b為一個(gè)基本傳送單位。對于每個(gè)所傳送的值，無(wú)論是基本類(lèi)型還是構造類(lèi)型，都由TLV三個(gè)字段組成。TLV分別指標識類(lèi)型標識符域(TAG)、數據長(cháng)度域(LENGTH)和數據域(VALUE)字段。其中，數據域可以多重嵌套其他數據元素的TLV字段。BER編碼的具體格式如圖3所示。 


 


在CAP協(xié)議描述中，以localValue，length，operator-code，errorcode分別對應BER編碼中的TLV，組成樹(shù)狀數據結構圖[1]，具體解碼設計將在下面分析。

3.3.2 解碼器實(shí)現方案

在通信測試儀表中主要是對協(xié)議及信令的PDU進(jìn)行操作，為滿(mǎn)足對PDU的公共操作我們制定了CPdu基類(lèi)，主要實(shí)現對PDU的創(chuàng )建、刪除、合并、內存管理、長(cháng)度檢查、指針操作等基本功能。在繼承CPdu類(lèi)的基礎上，我們派生出CPduCap類(lèi)，在類(lèi)CPduCap中設定外部接口函數int Deeode(CString&res)，完成詳細解碼過(guò)程，并通過(guò)引用傳遞的方式將解碼結果置于CString類(lèi)型的字符串內，便于主控方調用解碼結果。返回值結果定義如下：1：非本層PDU，不操作res；0：成功解碼；1：本層PDU，解碼出錯，錯誤信息加到結果字符串中。

由于A(yíng)SN.1語(yǔ)法的特點(diǎn)，Decode(CString＆res)函數采用樹(shù)狀遍歷嵌套調用的方式進(jìn)行解碼，直至解到BER的基礎函數為止。

在基礎解碼函數中，我們大量使用C++標準模板庫中的模板類(lèi)：容器std：：vector。vector是一個(gè)多功能的，能夠操作多種數據結構和算法的模板類(lèi)和函數庫，在A(yíng)SN．1復雜數據機構的環(huán)境下，vector的使用方便了對各種數據類(lèi)型進(jìn)行讀取、存儲、轉換操作。

詳細解碼的實(shí)現是對通信協(xié)議進(jìn)行深層次分析，以及統計、CDR合成的基礎，下面主要關(guān)注CAP CDR合成的實(shí)現。

3.3.3 呼叫合成器實(shí)現方案

呼叫合成器的主要功能就是根據到達的幀信息和呼叫信息，將幀消息按呼叫歸類(lèi)，即把消息ID加入到相應的CDR記錄中，并在呼叫結束時(shí)通知CDR緩存。CDR(calldata record)在PSTN中表示呼叫數據記錄，現在延伸意思為一個(gè)完整的流程，CDR合成是上述功能的基礎，對網(wǎng)絡(luò )中消息按信令流程進(jìn)行歸類(lèi)，并用索引方式把這些消息聯(lián)系到一起，然后才便于完成諸如呼叫跟蹤和呼損統計等高級功能。CDR合成算法主要是根據一些關(guān)鍵參數進(jìn)行查找、匹配來(lái)確定是否屬于同一個(gè)消息流程，因此在這個(gè)過(guò)程中，需要一些臨時(shí)存儲方式來(lái)保存沒(méi)有匹配到的消息，在內存分配上比較復雜，涉及動(dòng)態(tài)分配內存[5]。

移動(dòng)智能網(wǎng)應用部分(CAP)是在7號信令的SCCP/TCAP之上的，即CAP為T(mén)CAP的用戶(hù)(也稱(chēng)TC用戶(hù))，直接與TCAP的成分子層相連。CAP使用TCAP所提供的TC請求原語(yǔ)將要發(fā)送的CAP消息傳送至TCAP成分子層，然后再通過(guò)TCAP的事物處理子層、SCCP以及MTP將消息發(fā)到對端，或者使用TCAP所提供的指示原語(yǔ)接收對端發(fā)來(lái)的CAP消息。

TCAP有兩個(gè)重要概念：對話(huà)和操作。在網(wǎng)絡(luò )中一對節點(diǎn)之間使用TCAP進(jìn)行的所有通信都被結構化為對話(huà)。例如，為處理一個(gè)智能呼叫而在SSP和SCP之間進(jìn)行的所有通信可構成一個(gè)對話(huà)。在對話(huà)過(guò)程中交換的信息元素稱(chēng)為操作，CAP協(xié)議的消息即存放在這些信息元素中傳輸。操作由源TC用戶(hù)調用，請求目的地TC用戶(hù)執行該操作指定的動(dòng)作。在這個(gè)過(guò)程中，每個(gè)成份處理TC原語(yǔ)均帶有一個(gè)事務(wù)ID(也稱(chēng)對話(huà)ID)，成份子層收到此原語(yǔ)后，就將收到的對話(huà)ID與其相同的所有成份分配給這一對話(huà)。因此，我們在CAP的CDR過(guò)程中，以Transac-tionID作為關(guān)鍵字CDR ID在數據結構中進(jìn)行查找，匹配，確定惟一的CDR流程。TransactionID又分源事務(wù)ID和目的事務(wù)ID，分別存在于不同的TC原語(yǔ)中。

在呼叫合成實(shí)現中，最主要有兩個(gè)方法：

(1)設定CDR緩存的方法void SetCdrBuffer(CAPCDR BUF*pBuf)：其中CAP CDR BUF是包含CCapCDR的CDR緩存模板類(lèi)，此函數指定了CDR記錄緩存的位置。

(2)CDR處理函數：void Handle(const CallInfoCap&CapInfo,const NgnPktInfo＆ PktInfo)。他是進(jìn)行呼叫合成的核心，也是設計的關(guān)鍵。他有兩個(gè)參數，分別是該協(xié)議呼叫信息和數據幀信息。其基本流程如圖4所示。

其中，判斷某CDR是否已緩存，通知CDR緩存該CDR已結束和向緩存中添加新的CDR都需要調用CDR緩存模板類(lèi)的方法，對于CAP協(xié)議的CDR子類(lèi)：CCapCDR，聲明一個(gè)CAP CDR緩存類(lèi)型方法如下：ty-pedef CCallBuf<CCapCDR>CAP CDR BUF。

在緩存操作中的具體實(shí)現如下：

(1)查詢(xún)某CDR是否已緩存，利用CDR緩存的Search方法：

newCdr.nLinkID=nLinkld：
//設定關(guān)聯(lián)屬性(根據協(xié)議類(lèi)型增加)
_tcscpy(newCdr.Call ID，Caplnfo.Call ID)；
CCapCDR*pFind=m pCdrBuf=->Search(newCdr);
//查詢(xún)該CDR是否已存在

(2)向緩存中添加新的CDR：使用InsertNewCDR方法：

CCapCDR*pFind=m pCdrBuf->InsertNewCDR(newCdr)；

(3)通知緩存某CDR已結束：

bool bReturn=m pCdrlBuf->CallCompleted(*pFind)；CDR呼叫其他相關(guān)分析在此不再贅述。

4 軟件運行實(shí)現結果

在模塊的整個(gè)開(kāi)發(fā)流程中，每一步都要進(jìn)行軟件的測試工作，以保證整個(gè)模塊開(kāi)發(fā)工作的正確性。下面是軟件實(shí)測后進(jìn)行CDR合成的結果，可以從圖5中看到，軟件實(shí)現了CAP的CDR功能，點(diǎn)擊單條消息名稱(chēng)可以看到消息的關(guān)鍵數據，在此不再進(jìn)行演示。




   

  

5 結 語(yǔ)

采用面向對象的思想，通過(guò)C++語(yǔ)言，我們實(shí)現了CAP軟件模塊。在模塊開(kāi)發(fā)流程結束后，通過(guò)現場(chǎng)測試，該軟件模塊完全符合中國移動(dòng)《軟交換測試儀表測試規范(征求稿)》中對移動(dòng)智能網(wǎng)測試的要求[6]，目前該軟件模塊已運用于商用通信測試儀表中。 

  

c++相關(guān)文章:c++教程

通信相關(guān)文章:通信原理