淺談通信網(wǎng)絡(luò)測(cè)試儀表CAP軟件模塊研究

　　1、引言
　　　　
　　本文研究的主要內(nèi)容是CAP消息的分析，一方面描述如何根據(jù)協(xié)議標(biāo)準(zhǔn)中規(guī)定的協(xié)議消息結(jié)構(gòu)進(jìn)行解碼，另一方面結(jié)合實(shí)際情況探討CAP消息的統(tǒng)計(jì)及呼叫數(shù)據(jù)記錄合成等功能。
　　
　　2、CAP協(xié)議概述
　　
　　智能網(wǎng)是通信技術(shù)和計(jì)算機(jī)技術(shù)相融合的經(jīng)*例，其基本思想是將業(yè)務(wù)控制智能從交換網(wǎng)絡(luò)中分離出來(lái)，以No.7信令系統(tǒng)為橋梁，使交換網(wǎng)絡(luò)的控制信息與大容量分布式數(shù)據(jù)庫(kù)起來(lái)，集中控制，以方便新業(yè)務(wù)的引入和快速適應(yīng)不斷變化的市場(chǎng)需求，不必像過(guò)去那樣在大范圍多機(jī)種的交換機(jī)上進(jìn)行繁雜的修改。
　　
　　為了在移動(dòng)通信系統(tǒng)中引入智能網(wǎng)，歐洲電信標(biāo)準(zhǔn)研究所（ETSI）于1997年在GSMPhase2+上定義了CAM-EL（CustomisedApplicationsfornetworkEnhancedLogic，移動(dòng)網(wǎng)絡(luò)增強(qiáng)邏輯的客戶化應(yīng)用協(xié)議）。CAMEL協(xié)議的特征是為用戶提供一種網(wǎng)絡(luò)無(wú)關(guān)的業(yè)務(wù)一致性。即使用戶不在其所歸屬的公共陸地移動(dòng)網(wǎng)絡(luò)（HPLMN）中CAMEL協(xié)議也可以作為一種手段幫助網(wǎng)絡(luò)運(yùn)營(yíng)者向用戶提供特定的業(yè)務(wù)。CAP（CAMEI，ApplicationPart）是CAMEL的應(yīng)用部分，他基于智能網(wǎng)的INAP協(xié)議。CAP協(xié)議描述了移動(dòng)智能網(wǎng)中各個(gè)功能實(shí)體之間的標(biāo)準(zhǔn)
　　
　　通信規(guī)程[1,2]。
　　
　　CAP作為應(yīng)用層協(xié)議，與INAP，MAP同屬于TCAP的用戶[3]，他們?cè)谄咛?hào)信令系統(tǒng)中的位置如圖1所示。　　
　　移動(dòng)智能網(wǎng)系統(tǒng)中的各個(gè)設(shè)備往往是各個(gè)不同的廠家提供的，CAP定義的和無(wú)二義性就變得非常重要。目前CAP的語(yǔ)法的定義使用ASN.1。
　　
　　ASN.1（AbstractSyntaxNotationOne）就相當(dāng)于描述傳送語(yǔ)法的一種語(yǔ)言，他定義的編碼規(guī)則也就是從不同的協(xié)議語(yǔ)言到統(tǒng)一的傳送語(yǔ)法之間的轉(zhuǎn)換規(guī)則。因此，在具體實(shí)現(xiàn)時(shí)，必須在發(fā)送方設(shè)置一個(gè)ASN.1編碼器，將發(fā)送方所要傳送的符合發(fā)送方編程語(yǔ)法的消息格式轉(zhuǎn)換成為符合ASN.1編碼規(guī)則的格式然后再發(fā)送出去，然后在接收方設(shè)置一個(gè)ASN.1解碼器，將接收到的符合ASN.1編碼規(guī)則的消息格式解碼為符合接收方協(xié)議語(yǔ)法的消息格式。這樣，經(jīng)ASN.1描述的信息獨(dú)立于任何應(yīng)用系統(tǒng)及傳送網(wǎng)絡(luò)，不會(huì)因?yàn)閼?yīng)用環(huán)境的不同而引起二義性的解釋。
　　
　　ISO在制定ASN.1的同時(shí)也推出了ASN.1的兩種編碼規(guī)則，一是基本編碼規(guī)則（BasicEncodeRule，BER），詳細(xì)內(nèi)容請(qǐng)見(jiàn)X.690；另一個(gè)是數(shù)據(jù)包編碼規(guī)則（PacketEncodeRule，PER），詳細(xì)內(nèi)容請(qǐng)見(jiàn)X.691。BER和PER實(shí)際上都是一種傳送語(yǔ)法，他可以把復(fù)雜的用抽象語(yǔ)法描述的數(shù)據(jù)結(jié)構(gòu)表示成簡(jiǎn)單的數(shù)據(jù)流，從而便于在通信線路上傳送。PER就是在BER的基礎(chǔ)上，以減少編碼開(kāi)銷為目的而設(shè)計(jì)的編碼規(guī)則，相對(duì)BER編碼更加精簡(jiǎn)，但目前的通信協(xié)議仍以BER編碼居多，CAP協(xié)議遵循BER編碼規(guī)則[4]。
　　
　　3、CAP軟件模塊系統(tǒng)設(shè)計(jì)
　　
　　3.1CAP軟件模塊的設(shè)計(jì)要求
　　
　　對(duì)于通信網(wǎng)絡(luò)測(cè)試儀器的軟件模塊，CAP模塊需要滿足CAP消息的詳細(xì)解碼，信息提取、統(tǒng)計(jì)，CDR合成，過(guò)濾等功能。其設(shè)計(jì)主要考慮以下方面：
　　
　　（1）軟件的面向?qū)ο蠹澳K化設(shè)計(jì)
　　
　　在面向?qū)ο笏枷胂虏捎媚K化設(shè)計(jì)，模塊內(nèi)部的結(jié)構(gòu)清晰易懂，各模塊之間相對(duì)獨(dú)立。這樣便于檢查錯(cuò)誤，節(jié)省開(kāi)發(fā)時(shí)間，提高了軟件系統(tǒng)的穩(wěn)定性、可修改性和重用性。
　　
　　（2）與數(shù)據(jù)庫(kù)的配合
　　
　　通信測(cè)試系統(tǒng)涉及到數(shù)量相當(dāng)大的數(shù)據(jù)庫(kù)文件系統(tǒng)，信息提取，消息統(tǒng)計(jì)及CDR合成均需要同數(shù)據(jù)庫(kù)配合，因此，在軟件模塊設(shè)計(jì)期間要考慮模塊的數(shù)據(jù)庫(kù)實(shí)現(xiàn)問(wèn)題。
　　
　　（3）模塊的效率問(wèn)題
　　
　　為滿足測(cè)試儀表長(zhǎng)時(shí)間大負(fù)荷監(jiān)控和實(shí)時(shí)解碼統(tǒng)計(jì)等功能，模塊必須提高運(yùn)行效率。為了更好地提高軟件的性能，在軟件設(shè)計(jì)上，可以考慮采取多線程，流水線技術(shù)。
　　
　　3.2CAP模塊的結(jié)構(gòu)分析
　　
　　系統(tǒng)分析在用戶需求的基礎(chǔ)上，采用面向?qū)ο蟮乃枷雽?duì)CAP模塊具體分析，劃分系統(tǒng)的各個(gè)部分，明確他們之間的層次關(guān)系，然后將各個(gè)部分作為一個(gè)對(duì)象進(jìn)行功能分析，對(duì)每一層次的數(shù)據(jù)進(jìn)行加工處理，并向上一層提供必要的支持。根據(jù)軟件總體架構(gòu)方案協(xié)議消息處理流程如圖2所示。
　　其中，采集卡捕獲到的數(shù)據(jù)首先保存在消息緩存中；解碼器從消息緩存中取出消息逐條進(jìn)行粗略解碼，獲得每幀數(shù)據(jù)的幀信息和呼叫信息；這兩類信息按照協(xié)議類別交給呼叫合成器進(jìn)行呼叫合成，得到每個(gè)協(xié)議的CDR集合，保存在CDR緩存中；根據(jù)用戶需要進(jìn)行顯示和統(tǒng)計(jì)。統(tǒng)計(jì)功能可以直接面向CDR緩存進(jìn)行，也可以先將CDR輸入數(shù)據(jù)庫(kù)，在數(shù)據(jù)庫(kù)中進(jìn)行統(tǒng)計(jì)，然后輸出統(tǒng)計(jì)結(jié)果。對(duì)于CAP模塊，我們主要實(shí)現(xiàn)CAP解碼器和呼叫合成器的
　　
　　設(shè)計(jì)與實(shí)現(xiàn)。
　　
　　3.3CAP軟件模塊研究與實(shí)現(xiàn)
　　
　　3.3.1CAP協(xié)議解碼分析
　　
　　在對(duì)CAP進(jìn)行解碼分析前，首先要知道BER編碼的基本編碼格式。BER以8b為一個(gè)基本傳送單位。對(duì)于每個(gè)所傳送的值，無(wú)論是基本類型還是構(gòu)造類型，都由TLV三個(gè)字段組成。TLV分別指標(biāo)識(shí)類型標(biāo)識(shí)符域（TAG）、數(shù)據(jù)長(zhǎng)度域（LENGTH）和數(shù)據(jù)域（VALUE）字段。其中，數(shù)據(jù)域可以多重嵌套其他數(shù)據(jù)元素的TLV字段。BER編碼的具體格式如圖3所示。　　
　　在CAP協(xié)議描述中，以localValue，length，operator-code，errorcode分別對(duì)應(yīng)BER編碼中的TLV，組成樹(shù)狀數(shù)據(jù)結(jié)構(gòu)圖[1]，具體解碼設(shè)計(jì)將在下面分析。
　　
　　3.3.2解碼器實(shí)現(xiàn)方案
　　
　　在通信測(cè)試儀表中主要是對(duì)協(xié)議及信令的PDU進(jìn)行操作，為滿足對(duì)PDU的公共操作我們制定了CPdu基類，主要實(shí)現(xiàn)對(duì)PDU的創(chuàng)建、刪除、合并、內(nèi)存管理、長(zhǎng)度檢查、指針操作等基本功能。在繼承CPdu類的基礎(chǔ)上，我們派生出CPduCap類，在類CPduCap中設(shè)定外部接口函數(shù)intDeeode（CString&res），完成詳細(xì)解碼過(guò)程，并通過(guò)引用傳遞的方式將解碼結(jié)果置于CString類型的字符串內(nèi)，便于主控方調(diào)用解碼結(jié)果。返回值結(jié)果定義如下：1：非本層PDU，不操作res；0：成功解碼；1：本層PDU，解碼出錯(cuò)，錯(cuò)誤信息加到結(jié)果字符串中。
　　
　　由于ASN.1語(yǔ)法的特點(diǎn)，Decode（CString＆res）函數(shù)采用樹(shù)狀遍歷嵌套調(diào)用的方式進(jìn)行解碼，直至解到BER的基礎(chǔ)函數(shù)為止。
　　
　　在基礎(chǔ)解碼函數(shù)中，我們大量使用C++標(biāo)準(zhǔn)模板庫(kù)中的模板類：容器std：：vector。vector是一個(gè)多功能的，能夠操作多種數(shù)據(jù)結(jié)構(gòu)和算法的模板類和函數(shù)庫(kù)，在ASN．1復(fù)雜數(shù)據(jù)機(jī)構(gòu)的環(huán)境下，vector的使用方便了對(duì)各種數(shù)據(jù)類型進(jìn)行讀取、存儲(chǔ)、轉(zhuǎn)換操作。
　　
　　詳細(xì)解碼的實(shí)現(xiàn)是對(duì)通信協(xié)議進(jìn)行深層次分析，以及統(tǒng)計(jì)、CDR合成的基礎(chǔ)，下面主要關(guān)注CAPCDR合成的實(shí)現(xiàn)。
　　
　　3.3.3呼叫合成器實(shí)現(xiàn)方案
　　
　　呼叫合成器的主要功能就是根據(jù)到達(dá)的幀信息和呼叫信息，將幀消息按呼叫歸類，即把消息ID加入到相應(yīng)的CDR記錄中，并在呼叫結(jié)束時(shí)通知CDR緩存。CDR（calldatarecord）在PSTN中表示呼叫數(shù)據(jù)記錄，現(xiàn)在延伸意思為一個(gè)完整的流程，CDR合成是上述功能的基礎(chǔ)，對(duì)網(wǎng)絡(luò)中消息按信令流程進(jìn)行歸類，并用索引方式把這些消息到一起，然后才便于完成諸如呼叫跟蹤和呼損統(tǒng)計(jì)等功能。CDR合成算法主要是根據(jù)一些關(guān)鍵參數(shù)進(jìn)行查找、匹配來(lái)確定是否屬于同一個(gè)消息流程，因此在這個(gè)過(guò)程中，需要一些臨時(shí)存儲(chǔ)方式來(lái)保存沒(méi)有匹配到的消息，在內(nèi)存分配上比較復(fù)雜，涉及動(dòng)態(tài)分配內(nèi)存[5]。
　　
　　移動(dòng)智能網(wǎng)應(yīng)用部分（CAP）是在7號(hào)信令的SCCP/TCAP之上的，即CAP為TCAP的用戶（也稱TC用戶），直接與TCAP的成分子層相連。CAP使用TCAP所提供的TC請(qǐng)求原語(yǔ)將要發(fā)送的CAP消息傳送至TCAP成分子層，然后再通過(guò)TCAP的事物處理子層、SCCP以及MTP將消息發(fā)到對(duì)端，或者使用TCAP所提供的指示原語(yǔ)接收對(duì)端發(fā)來(lái)的CAP消息。
　　
　　TCAP有兩個(gè)重要概念：對(duì)話和操作。在網(wǎng)絡(luò)中一對(duì)節(jié)點(diǎn)之間使用TCAP進(jìn)行的所有通信都被結(jié)構(gòu)化為對(duì)話。例如，為處理一個(gè)智能呼叫而在SSP和SCP之間進(jìn)行的所有通信可構(gòu)成一個(gè)對(duì)話。在對(duì)話過(guò)程中交換的信息元素稱為操作，CAP協(xié)議的消息即存放在這些信息元素中傳輸。操作由源TC用戶調(diào)用，請(qǐng)求目的地TC用戶執(zhí)行該操作的動(dòng)作。在這個(gè)過(guò)程中，每個(gè)成份處理TC原語(yǔ)均帶有一個(gè)事務(wù)ID（也稱對(duì)話ID），成份子層收到此原語(yǔ)后，就將收到的對(duì)話ID與其相同的所有成份分配給這一對(duì)話。因此，我們?cè)贑AP的CDR過(guò)程中，以Transac-tionID作為關(guān)鍵字CDRID在數(shù)據(jù)結(jié)構(gòu)中進(jìn)行查找，匹配，確定惟一的CDR流程。TransactionID又分源事務(wù)ID和目的事務(wù)ID，分別存在于不同的TC原語(yǔ)中。
　　
　　在呼叫合成實(shí)現(xiàn)中，zui主要有兩個(gè)方法：
　　
　　（1）設(shè)定CDR緩存的方法voidSetCdrBuffer（CAPCDRBUF*pBuf）：其中CAPCDRBUF是包含CCapCDR的CDR緩存模板類，此函數(shù)了CDR記錄緩存的位置。
　　
　　（2）CDR處理函數(shù)：voidHandle（constCallInfoCap&CapInfo,constNgnPktInfo＆PktInfo）。他是進(jìn)行呼叫合成的核心，也是設(shè)計(jì)的關(guān)鍵。他有兩個(gè)參數(shù)，分別是該協(xié)議呼叫信息和數(shù)據(jù)幀信息。其基本流程如圖4所示。
　　
　　其中，判斷某CDR是否已緩存，通知CDR緩存該CDR已結(jié)束和向緩存中添加新的CDR都需要調(diào)用CDR緩存模板類的方法，對(duì)于CAP協(xié)議的CDR子類：CCapCDR，聲明一個(gè)CAPCDR緩存類型方法如下：ty-pedefCCallBuf<CCapCDR>CAPCDRBUF。
　　
　　在緩存操作中的具體實(shí)現(xiàn)如下：
　　
　　（1）查詢某CDR是否已緩存，利用CDR緩存的Search方法：
　　
　　newCdr.nLinkID=nLinkld：
　　
　　//設(shè)定關(guān)聯(lián)屬性（根據(jù)協(xié)議類型增加）
　　
　　_tcscpy（newCdr.CallID，Caplnfo.CallID）；
　　
　　CCapCDR*pFind=mpCdrBuf=->Search（newCdr）;
　　
　　//查詢?cè)揅DR是否已存在
　　
　　（2）向緩存中添加新的CDR：使用InsertNewCDR方法：
　　
　　CCapCDR*pFind=mpCdrBuf->InsertNewCDR（newCdr）；
　　
　　（3）通知緩存某CDR已結(jié)束：
　　
　　boolbReturn=mpCdrlBuf->CallCompleted（*pFind）；CDR呼叫其他相關(guān)分析在此不再贅述。
　　
　　4、軟件運(yùn)行實(shí)現(xiàn)結(jié)果
　　
　　在模塊的整個(gè)開(kāi)發(fā)流程中，每一步都要進(jìn)行軟件的測(cè)試工作，以保證整個(gè)模塊開(kāi)發(fā)工作的正確性。下面是軟件實(shí)測(cè)后進(jìn)行CDR合成的結(jié)果，可以從圖5中看到，軟件實(shí)現(xiàn)了CAP的CDR功能，點(diǎn)擊單條消息名稱可以看到消息的關(guān)鍵數(shù)據(jù)，在此不再進(jìn)行演示。　　
　　5、結(jié)語(yǔ)
　　
　　采用面向?qū)ο蟮乃枷耄ㄟ^(guò)C++語(yǔ)言，我們實(shí)現(xiàn)了CAP軟件模塊。在模塊開(kāi)發(fā)流程結(jié)束后，通過(guò)現(xiàn)場(chǎng)測(cè)試，該軟件模塊*符合中國(guó)移動(dòng)《軟交換測(cè)試儀表測(cè)試規(guī)范（征求稿）》中對(duì)移動(dòng)智能網(wǎng)測(cè)試的要求[6]，目前該軟件模塊已運(yùn)用于商用通信測(cè)試儀表中。