IMS應用層協(xié)議研究的設計

1、編 號 09成 績教師簽字 長春建筑學院電氣與信息學院課程設計報告1. 課程設計題目：IMS應用層協(xié)議研究專 業(yè) ： 通信工程 班 級： 通信1201 學生姓名： 尚斌成 學生學號： 122700109 課程名稱： 現(xiàn)代交換技術課程設計 任課教師： 范亞芹 設計時間： 第16-17周 設計地點： 城建 412 2015年 12月 31日評語：任課教師（簽名）： 年 月 日摘 要 基于SIP協(xié)議的IMS系統(tǒng)是未來3G時代實現(xiàn)多媒體應用的關鍵組成部分,與之相關的標準已經(jīng)成為通信和網(wǎng)絡界的研究熱點.IMS域中在應用層主要使用的協(xié)議是會話初始協(xié)議（SIP）和Diameter.其中SIP主要用于呼叫和業(yè)

2、務控制、Diameter主要用于鑒權、授權、計費（AAA）方面.本文在介紹IMS系統(tǒng)架構和SIP信令協(xié)議的基礎上,首先分析了IMS系統(tǒng)架構的總體情況,針對其中的應用層協(xié)議SIP與Diameter進行深入研究.并在此基礎上設計了一種針對IMS中應用層協(xié)議進行測試的協(xié)議測試工具,并在實際測試中使用此測試工具發(fā)現(xiàn)了待測網(wǎng)元的許多故障,取得了良好的測試效果.關鍵詞:IMS, Sip,Diameter, 協(xié)議測試工具目錄第一章 設計背景11.1設計背景13 是基于統(tǒng)一協(xié)議的分組網(wǎng)絡體系.1第二章 設計要求22.1 設計要求22.2設計目的2第三章總體方案33.1 IMS系統(tǒng)簡介33.1.1 IMS系統(tǒng)簡

3、介33.1.2 總體方案3第四章具體實現(xiàn)54.1系統(tǒng)模塊組成54.1.1 系統(tǒng)模塊組成54.1.2 IMS系統(tǒng)架構5圖4-1 IMS系統(tǒng)架構圖54.1.3 IMS主要網(wǎng)元描述64.1.4 SIP 協(xié)議結構74.1.5 SIP74.1.6 Diameter協(xié)議84.1.7 Diameter計費104.2測試工具設計114.3子系統(tǒng)設計實現(xiàn)124.4主控進程144.5 工作原理164.6業(yè)務處理進程業(yè)務174.7 系統(tǒng)測試發(fā)現(xiàn)的部分故障184.8結束語20第五章 心得體會21參考文獻22第一章 設計背景1.1設計背景 隨著第三代移動通信（3G）的發(fā)展,通信系統(tǒng)不僅要滿足傳統(tǒng)的語音傳輸業(yè)務,而且還要

4、求能夠進行數(shù)據(jù)和多媒體等多種方式通信.第三代合作伙伴項目（3GPP）在第5版協(xié)議體系（R5）中提出了一種通訊核心網(wǎng)架構IP多媒體子系統(tǒng)（IMS）.IMS是一種全IP的網(wǎng)絡架構,用來處理多種多樣的IP多媒體業(yè)務以及控制整個復雜的呼叫流程. 目前,國際上研究NGN的4大標準化組織分別是ITU（國際電信聯(lián)盟）、ETSI、3GPP和IETF.普遍的認識是NGN將是基于軟交換技術的全IP的開放的網(wǎng)絡.NGN有三大特點：1 是業(yè)務驅動型的網(wǎng)絡,業(yè)務與控制完全分離,控制與承載完全分離;2 采用分層的全開放網(wǎng)絡,具有獨立的模塊化結構;3 是基于統(tǒng)一協(xié)議的分組網(wǎng)絡體系. 所以NGN將是一個四層結構的網(wǎng)絡,分別是

5、業(yè)務層、控制層、承載層和接入層. NGN的描繪為當前移動通信網(wǎng)的發(fā)展指明了方向.第二代移動通信系統(tǒng)向第三代移動通信系統(tǒng)演進的過程中也逐步向NGN的目標靠攏,在GSM向UMTS的演進過程中,3GPP分別提出了R99, R4,R5,R6和R7版本,為GSM向UMTS過渡提供了一條平滑的演進之路.R4在核心網(wǎng)電路域引入了軟交換,實現(xiàn)了控制與承載分離.R5在分組域增加了IMS,提出了全IP的網(wǎng)絡架構,用來處理多種多樣的IP多媒體業(yè)務以及控制整個復雜的呼叫流程.R6在網(wǎng)絡架構方面已沒有太大的變更,主要是增加了一些新的功能特性,以及對已有功能特性的增強.R7重點解決IMS支持固定接入的問題.自3GPP在2

6、002年R5版本中提出IMS架構到R6, R7版本的逐步細化,IMS已經(jīng)成為NGN的一個熱點技術,IMS作為未來融合網(wǎng)絡的統(tǒng)一核心和控制地位,目前已經(jīng)在業(yè)界得到普遍的共識. 第二章 設計要求2.1 設計要求 1 簡述研究背景和目的; 2 詳細討論IMS系統(tǒng)架構的總體情況; 3 針對其中的應用層協(xié)議SIP與Diameter進行深入研究; 4 編寫設計報告,要求包括方案選擇,程序清單,調(diào)試過程,測試結果及心得.2.2設計目的 IMS是網(wǎng)絡演進的重要階段,對按照協(xié)議要求開發(fā)實現(xiàn)的各個網(wǎng)絡實體進行協(xié)議一致性測試也是必不可少的.實踐表明,越早發(fā)現(xiàn)開發(fā)版本中的bug,修正時所需投入的人力物力以及后期維護費

7、用就越低.因此實現(xiàn)一種針對IMS中應用層協(xié)議進行測試的協(xié)議測試工具,用測試工具在系統(tǒng)測試中校驗網(wǎng)絡實體功能與協(xié)議一致性是具有現(xiàn)實意義的.第三章總體方案3.1 IMS系統(tǒng)簡介3.1.1 IMS系統(tǒng)簡介 要針對IMS中應用層協(xié)議研究與測試,首先要了解什么是IMS.IMS簡單的說是一種實現(xiàn)IP多媒體業(yè)務的建立、維護及管理等功能的核心網(wǎng)絡體系結構.本章首先概述了IMS的發(fā)展與特點,接著針對3GPP提出的IMS系統(tǒng)架構做簡要的說明,并針對此系統(tǒng)架構內(nèi)部網(wǎng)元進行簡要的功能描述. IMS是推動FMC發(fā)展最重要的技術動力,也是開啟融合世界的鑰匙.這一點得到了包括ITU , ETSI TISPAN , 3GPP

8、2標準組織和運營商的廣泛認可接受.3GPP/3GPP2定義了IMS網(wǎng)絡組件及基礎架構,并盡可能協(xié)調(diào)保持一致性; ITU-T、ETSI（TISPAN）均將IMS作為下一代融合的框架,并進行深入研究;IETF定義了IMS框架下的SIP（Session Initiation Protocol,會話初始協(xié)議）,DIAMETER以及相關擴展等協(xié)議,并啟動了多項IMS相關工作.盡管基于不同的網(wǎng)絡現(xiàn)狀和發(fā)展策略,不同的運營商在IMS的部署策略上具有一定的差異性,但從全球范圍來看,IMS的商用部署和演進可以概括為如下過程：2005年全球主流市場實現(xiàn)了軟交換的規(guī)模建設（包括固定/移動軟交換）,PSTN (Pub

9、lic Switched Telephone Network,公共開關電話網(wǎng))基本停止建設,IMS的測試啟動;在IMS的商用部署和演進策略上,2005-2010年為第一階段,這個階段的主要特征是軟交換與IMS并存,軟交換是話音網(wǎng)絡建設最成熟的解決方案,而IMS的重點是提供IP多媒體業(yè)務,CSI則是IMS與CS（Circuit Switched Domain,電路域）開展并存業(yè)務的主要實現(xiàn)技術;2010年之后將進入IMS商用部署的第二階段,這個階段全IP的商業(yè)模式已經(jīng)成熟,電路域的話音業(yè)務將逐漸被基于IMS的Voice/Video over IP所替代.3.1.2 總體方案 本章主要研究了IMS

10、應用層協(xié)議中的Diameter協(xié)議,Diameter協(xié)議主要用于AAA方面.如IMS中的基礎網(wǎng)元CSCF與HSS之間的Cx/Dx接口采用的是Diameter消息進行交互. 測試工具不僅需要可以模擬終端進行測試,作為更高要求還需要可以模擬網(wǎng)元進行測試.那就提出測試工具不僅可以收發(fā)SIP消息,同樣還可以收發(fā)Diameter消息,以滿足如模擬HSS網(wǎng)元來測試CSCF的需求.滿足Diameter協(xié)議的測試需求是對此測試工具測試范圍的進一步提升.通過對IMS系統(tǒng)架構的分析和對IMS域內(nèi)應用層協(xié)議SIP和Diameter的研究,可以明確所需設計的針對IMS域內(nèi)網(wǎng)元進行協(xié)議測試的測試工具它的基礎功能是模擬終

11、端收發(fā)SIP消息,以觀察待測網(wǎng)元對收到SIP消息的響應情況.并且由于SIP協(xié)議的可擴充性,測試工具也需要可以不斷增添新的SIP消息以滿足新的測試需求.測試工具需要滿足一定的可維護性.而測試工具模擬網(wǎng)元可以收發(fā)Diameter消息,來滿足Diameter協(xié)議的測試需求是對此測試工具測試范圍的進一步提升. 第四章具體實現(xiàn)4.1系統(tǒng)模塊組成4.1.1 系統(tǒng)模塊組成 本章首先給出針對IMS域內(nèi)應用層協(xié)議測試的測試工具的設計概要,接著給出其具體子系統(tǒng)的實現(xiàn)方案,在子小節(jié)分別論述了系統(tǒng)控制子系統(tǒng)、VOS子系統(tǒng)、業(yè)務模擬子系統(tǒng)、碼流分析子系統(tǒng)、操作界面子系統(tǒng)的實現(xiàn)原理. 4.1.2 IMS系統(tǒng)架構 圖4-1

12、為IMS系統(tǒng)架構圖,圖中中間為IMS域,左下方為與CS互通時所需網(wǎng)元,右下方為與PS（Packet Switched Domain,分組域）互通時所需網(wǎng)元.本文將重點究IMS域內(nèi)的網(wǎng)元.圖4-1 IMS系統(tǒng)架構圖 從層次上看,IMS可劃分為三層結構：業(yè)務應用層、控制層、連接層.業(yè)務應用層:由應用和內(nèi)容服務器組成,負責為用戶提供增值業(yè)務.如IMS標準中規(guī)定的通用業(yè)務使能模塊,可以像執(zhí)行SIP AS（Application Server,應用服務器）中的業(yè)務一樣進行部署.控制層:由網(wǎng)絡控制服務器組成,負責管理呼叫或會話設置、修改、釋放.這些服務器中最重要的是CSCF（Call Session Co

13、ntrol Function,呼叫會話控制功能）,也就是常說的SIP服務器.而且,該層還包括多種支持功能如配置、計費以及運營維護功能.邊界網(wǎng)關負責與其他運營商網(wǎng)絡和其他類型的網(wǎng)絡之間的互通,或者它們彼此內(nèi)部的網(wǎng)絡互通.連接層:由用于骨干和接入網(wǎng)絡的路由器及交換機組成.從邏輯上看,IMS可劃分為三個邏輯區(qū)域：歸屬域（Home Network）,拜訪域（Visit Network）和網(wǎng)關域（Gateway Network）.歸屬域和地理區(qū)域沒有本質(zhì)的關系,但是和SIP URI(Unified Resource Identifier,統(tǒng)一資源標識) 如SIP：userdomain中的domain有對

14、應關系,一般來說,每個domain都應該有自己的歸屬域.拜訪域包含SIP客戶端和P-CSCF,P-CSCF本質(zhì)是一個SIP Proxy,其作用是受理所有SIP客戶端的注冊和呼叫,根據(jù)主叫/被叫的SIP URI去定位其相的歸屬域,以完成注冊過程和呼叫接續(xù).多個P-CSCF可以共存以實現(xiàn)負載分擔,在規(guī)劃網(wǎng)絡的時候,可以根據(jù)該區(qū)域內(nèi)活動用戶數(shù)目（包括本地用戶和漫游用戶）來配置P-CSCF的數(shù)量.網(wǎng)關域的功能非常簡單,就是完成IMS和話音交換網(wǎng)（包括PSTN,PLMN等）的互通.對于現(xiàn)階段IMS在固定網(wǎng)中的部署,其實CS域在添加SIP處理模塊后,可以完全起到網(wǎng)關域的作用,當然在全SIP網(wǎng)絡中網(wǎng)關域將不

15、復存在.4.1.3 IMS主要網(wǎng)元描述 3GPP IMS的主要功能實體包括：CSCF（Call Session Control Function,呼叫會話控制功能）、HSS（Home Subscriber Server,歸屬用戶服務器）、SLF（Subscription Locator Function,簽約定位功能）、MRFC（Multimedia Resource Function Controller,多媒體資源控制器）、MRFP（Multimedia Resource Function Processor,多媒體資源處理器）.通相關的輔助設備包括：SGW（Signaling Gatew

16、ay,信令網(wǎng)關）、MGCF(Media Gateway Control Function,媒體網(wǎng)關控制功能)、IM-MGW (IP MultimediaSubsystem Media Gateway Function,IMS媒體網(wǎng)關功能)、BGCF(Breakout Gateway Control Function,出口網(wǎng)關控制功能) Sip協(xié)議協(xié)議統(tǒng)一是NGN的一大特征,IMS同樣具有這個特征.IMS中各個網(wǎng)元之間的接口采用統(tǒng)一的應用層協(xié)議進行通信,其主要使用的協(xié)議是SIP和Diameter.本章對SIP協(xié)議進行了深入研究,在各個子小節(jié)中分別論述了其協(xié)議結構、消息格式、網(wǎng)絡結構、實體功能、對

17、話與會話及可擴充性.SIP協(xié)議SIP是一個應用層的控制協(xié)議,可以用來建立、修改、和終止多媒體會話（或者會議）,例如Internet 電話.SIP也可以邀請參與者參加已經(jīng)存在的會話,比如多方會議.SIP協(xié)議允許在一個已經(jīng)存在的會話中方便的增加（或者刪除）媒體.SIP支持名字映射和重定向服務,可用于支持個人移動業(yè)務,對用戶而言可以使用一個唯一的外部標志而不用關心實際網(wǎng)絡位置.SIP在以下5個方面支持建立和終止多媒體通信：1） 用戶定位（User location）：確定用于通訊的終端系統(tǒng);2） 用戶可用性（User availability）：確定被叫方是否空閑及是否愿意進行通訊 3）3）用戶能力

18、（User capabilities）：確定使用的媒體和媒體參數(shù);4） 會話建立（Session setup）：邀請和提示被叫,在主被叫之間傳遞呼叫參數(shù); 5） 會話管理（Session management）：包括會話轉移和終結會話、修改會話參數(shù)、 調(diào) 用業(yè)務等. 4.1.4 SIP 協(xié)議結構 SIP 協(xié)議的結構可以用以下四層來描述：語法及編碼層它的編碼使用增強Backus-Nayr形式語法（BNF）來規(guī)定.傳輸層傳輸層定義了客戶端如何通過網(wǎng)絡發(fā)送請求及接收響應,以及服務器端如 何接收請求并發(fā)送響應.所有SIP 邏輯實體都包含此層.事務層事務是SIP的基本元素.除stateless prox

19、y 外的所有SIP 邏輯實體core 均是事務用戶.4.1.5 SIP 網(wǎng)絡結構圖4-2繪制了Sip網(wǎng)絡實體: 圖4-2 Sip網(wǎng)絡實體SIP是一個應用層的控制協(xié)議,可以用來建立、修改、和終止多媒體會話.其設計思想沿襲了IETF一貫的簡單性、可擴展性和可編程性. IMS域內(nèi)的UE終端采SIP消息實現(xiàn)發(fā)起、修改和終止多媒體會話.測試工具需要可以支持模擬終端進行測試,即測試工具要可以發(fā)出各種所需的SIP消息,以觀察待測網(wǎng)元對收到SIP消息的響應情況.并且由于SIP協(xié)議的可擴充性,測試工具也需要可以不斷增添新的SIP消息以滿足新的測試需求.滿足SIP協(xié)議的測試需求是此測試工具的基礎功能.4.1.6

20、Diameter協(xié)議 IMS中廣泛使用的另一個應用層協(xié)議是Diameter.Diameter協(xié)議是由IETF開發(fā)的AAA協(xié)議,是基于遠程撥入用戶服務（RADIUS）協(xié)議的演進.本章對Diameter協(xié)議進行深入研究,在各個子小節(jié)中分別論述了其消息格式、網(wǎng)絡節(jié)點、基礎功能、會話和計費. Diameter協(xié)議Diameter協(xié)議族包括基礎協(xié)議（Diameter Base Protocol）和各種應用協(xié)議.基礎協(xié)議提供了作為一個AAA協(xié)議的最低需求,是Diameter網(wǎng)絡節(jié)點都必須實現(xiàn)的功能,包括節(jié)點間能力的協(xié)商、Diameter消息的接收及轉發(fā)、計費信息的實時傳輸?shù)?應用協(xié)議則充分利用基礎協(xié)議提供

21、的消息傳送機制,規(guī)范相關節(jié)點的功能以及其特有的消息內(nèi)容,來實現(xiàn)應用業(yè)務的AAA.基礎協(xié)議可以作為一個計費協(xié)議單獨使用,但一般情況下需與某個應用一起使用.圖3.為Diameter協(xié)議族結構.圖4-3 Diameter協(xié)議族結構網(wǎng)絡節(jié)點在Diameter協(xié)議中,包括多種類型的Diameter節(jié)點.除了Diameter客戶端和Diameter服務器外,還有Diameter中繼、Diameter代理、Diameter重定向器和Diameter協(xié)議轉換器. Diameter中繼：能夠從Diameter請求消息中提取信息,再根據(jù)Diameter基于域的路由表的內(nèi)容決定消息發(fā)送的下一跳Diameter節(jié)點.

22、Diameter中繼只對過往消息進行路由信息的修改,而不改動消息中的其他內(nèi)容. Diameter代理：根據(jù)Diameter路由表的內(nèi)容決定消息發(fā)送的下一跳Diameter節(jié)點.此外,Diameter代理能夠修改消息中的相應內(nèi)容.基礎協(xié)議規(guī)定了Diameter節(jié)點之間所有消息交互的原則,它關注能力協(xié)商、消息如何發(fā)送以及對等端如何最終被拒絕.Diameter節(jié)點間的網(wǎng)絡連接是在Diameter節(jié)點啟動過程中動態(tài)建立的基于TCP或者SCTP傳輸協(xié)議上的連接.對于一個Diameter節(jié)點,其對端節(jié)點,或者基于靜態(tài)配置,或者基于動態(tài)（利用SLP、DNS協(xié)議）發(fā)現(xiàn)一個Diameter節(jié)點具有和多個對等端通

23、信的能力,但與所有對等端均建立連接則不是有效的方法.基于每個域,一個Diameter節(jié)點應該與兩個對等端建立連接,即首要對等端和次要對等端.如果認為有必要,Diameter節(jié)點還可以建立其它的連接. 在成功建立一個等連接后,兩個Diameter節(jié)點將進行能力協(xié)商,交換協(xié)議版本、所支持的應用協(xié)議、安全模式等信息.能力協(xié)商是通過Diameter的能力交換請求（CER,Capabilities-Exchange-Request）和能力交換響應（CEA,Capabilities-Exchange-Answer）兩個Diameter消息的交互實現(xiàn)的.能力協(xié)商之后,應該把有關對端所支持的應用等信息保存在高

24、速緩存中,這樣就可以防止把對端不認識的消息和AVP發(fā)送給對端.對等連接可以被正常中止,這需要一個Diameter節(jié)點主動發(fā)起對等連接中止請求（DPR,Disconnect-Peer-Request）消息,對端收到此消息,并回答對等連接中止應答（DPA,Disconnect-Peer-Answer）消息后,先行中止底層連接.Diameter會話Diameter客戶端與Diameter服務器都可以組成相應的請求消息,發(fā)送給對方.正是從這點考慮,Diameter屬于對等協(xié)議（peer to peer）,而不是如RADIUS一樣的客戶/服務器模式的協(xié)議.處理用戶的接入,Diameter客戶端通過Dia

25、meter基礎協(xié)議和應用協(xié)議,與Diameter服務器進行一系列的信息交換,而這樣一個從發(fā)起到中止的一系列信息交互,在Diameter協(xié)議為一個用戶會話（User Session）. 一般的AAA業(yè)務可以大致分成兩類：一類包括用戶的認證和授權,可能還包括計費（如移動電話業(yè)務）;另一類則是僅包括對用戶的計費（如目前的主叫撥號接入業(yè)務）.為此,Diamete基礎協(xié)議提供對應的兩類用戶會話,為上層的應用服務.一個用戶會話的建立,一般是由Diameter客戶端發(fā)起,中間可以途徑若干Diameter代理、重定向器或協(xié)議轉換器,一直延伸到Diameter服務器.用戶會話的結束,完全由Diameter客戶端

26、決定,但服務器也可以先行發(fā)出中止用戶會話請求(ASR,Abort-Session-Request）,在客戶端同意中止請求的情況下,會響應中止用戶會話應答（ASA,Abort-Session-Answer）,然后再發(fā)出用戶會話結束請求,通知服務器結束用戶會話;否則用戶會話仍得以保持.在未得到服務器請求的情況下,客戶端也可以自行給服務器發(fā)出用戶會話結束請求,例如在客戶端自身異常,或是用戶接入異常等的情況下.通過對用戶會話的建立和結束的控制,Diameter應用很容易實現(xiàn)可靠的以用戶為單位的業(yè)務資源管理.Diameter基礎協(xié)議中并不包含任何的授權請求消息,因為這些是應用相關的即在Diameter的

27、應用文檔中定義. 4.1.7 Diameter計費 當用戶被允許接入時,Diameter客戶端將根據(jù)情況產(chǎn)生針對用戶的計費信息.這些計費信息將被封裝在具體Diameter應用專有的AVP內(nèi),由Diameter基礎協(xié)議中定義的計費請求（ACR,Accounting-Request）消息,傳送給Diameter服務器.服務器將響應計費應答（ACA,Accounting-Answer）消息,指示計費成功或拒絕.客戶端只有在收到成功的計費響應時,才能清除已經(jīng)被發(fā)送的計費記錄.當收到計費拒絕指示時,客戶端將中止用戶接入.Diameter支持實時的計費,客戶端通過在首次計費請求/響應交互過程中協(xié)商好的計費

28、消息間歇時間,定時向服務器發(fā)送已收集的計費信息.這種實時計費確保了對用戶信用的實時檢查.4.2測試工具設計 測試工具第一階段設計目標是：在充分考慮整個完整系統(tǒng)架構的基礎上,先實現(xiàn)由一個Console(控制臺)和一個Tester（測試器）在同一臺PC上組成的最簡TesterStudio系統(tǒng).系統(tǒng)架構如圖4-4所示.圖 4-4系統(tǒng)架構 其中Console為一個窗口操作界面,可以進行信令的編輯,執(zhí)行.Tester由各虛擬單板組成,主要是1個Vomp,用于執(zhí)行操作維護,2個Vmp,分別執(zhí)行業(yè)務模擬和碼流分析.系統(tǒng)可由一個Console和一個或多個Tester組成,Console 提供人機界面,各Tes

29、ter執(zhí)行實際的測試,Console從各Tester讀取測試結果,Console同時負責控制各Tester.Console提供一個客戶端工具集,可以由一個或者多個進程組成.Tester由若干虛擬處理板構成,這些虛擬處理板運行在一臺PC機上,一個虛擬單板對應一個操作系統(tǒng)進程.由于Console和Tester在同一個PC上,它們之間通訊IP采用127.0.0.1,各虛擬單板之間通信IP同樣設置,Tester對待側網(wǎng)元公開的IP為PC的IP,Sip消息測試時采用端口5060,Diameter消息測試時采用端口3868.其它非MP虛擬處理板提供傳輸層以下信令處理. Test Studio系統(tǒng)的主要功能

30、是執(zhí)行測試用例,獲得測試結果.系統(tǒng)的處理流程主要分為以下幾個階段：系統(tǒng)啟動初始化階段、測試用例執(zhí)行階段、測試結果分析階段.系統(tǒng)啟動和初始化是Test Studio系統(tǒng)提供服務的準備階段.Test Studio系統(tǒng)首先必須進行必要的啟動和初始化,包括了Tester和Console的啟動和初始化.對于Tester來說,包括了VOMP虛擬單板非VOMP虛擬單板的啟動和初始化.4.3子系統(tǒng)設計實現(xiàn) 系統(tǒng)控制子系統(tǒng)完成Tester上各虛擬單板版本加載,啟動和初始化以及Console的啟動和初始化.系統(tǒng)控制子系統(tǒng)主要實現(xiàn)三個方面： 1）實現(xiàn)虛擬單板啟動初始化通用流程,流程如圖4-5所示. 2）實現(xiàn)虛擬單板

31、主控用戶進程,流程如圖4-6所示. 3）實現(xiàn)通訊控制用戶進程.Tester上單板的啟動和初始化Tester上不同類型的單板,具體功能完全是由用戶進程來提供的,不同類型的單板加載不同種類的用戶進程,從而具有不同的功能.對于各種虛擬單板的啟動和初始化來說設計上可以做到統(tǒng)一. 圖4-5 虛擬單板啟動和初始化流程圖4-5是虛擬單板啟動和初始化的通用流程,任何類型的虛擬單板都是一樣的,當初始化VOS成功,VOS已經(jīng)進入服務狀態(tài),虛擬單板就向主控進程發(fā)送上電消息,啟動主控進程,然后系統(tǒng)控制權就交給主控進程,虛擬單板啟動和初始化通用流程結束.初始化VOS,是調(diào)用VOS提供的接口進行的,主要完成了VOS核心數(shù)

32、據(jù)結構的初始化,根據(jù)虛擬單板的邏輯類型、任務配置表、用戶進程配置表來創(chuàng)建調(diào)度任務和其它各種任務,創(chuàng)建并且掛載用戶進程,啟動各種任務.表4-1列出了第一階段虛擬單板需要支持的任務.表4.1第一階段虛擬單板需要支持的任務其中調(diào)度任務是VOS進程調(diào)度的核心任務、板間通訊監(jiān)聽任務、通信處理任務是VOS進程通訊的核心任務,定時器掃描任務是VOS定時管理的核心任務.前后臺通訊監(jiān)聽任務只在VOMP上有,用于VOMP和Console通訊時監(jiān)聽TCP連接.表4-2不同邏輯類型的虛擬單板支持的用戶進程所有單板都有主控進程,主控進程是虛擬單板啟動、初始化后執(zhí)行的首個用戶進程,它負責啟動其它用戶進程.對于通訊控制進程

33、來說,VOMP和非VOMP單板的功能有所不同,主要是用于單板邏輯地址和通訊地址映射關系的建立.此外還有各種不同的用戶進程,執(zhí)行的不同的功能.所有這些用戶進程分屬Test Studio不同的子系統(tǒng),子系統(tǒng)實現(xiàn)的關鍵就是相關用戶進程的設計和實現(xiàn).VOS將以上述表4-1、表4-2為基礎,為各種邏輯類型的單板統(tǒng)一維護任務配置表和用戶進程配置表.虛擬單板啟動和初始化流程在調(diào)用VOS初始化接口時需要提供單板的邏輯類型參數(shù),這包括所屬模塊、單元的類型,VOS將根據(jù)邏輯類型查表進行相應的處理.4.4主控進程 主控進程是一個用戶進程,虛擬單板啟動和初始化完成后,首先向主控進程發(fā)送啟動消息,將控制權交給主控進程.

34、主控進程主要完成向其它用戶進程發(fā)送啟動消息,啟動其它各種用戶進程.所有用戶進程成功啟動后,如果虛擬單板是VOMP,則還要根據(jù)配置信息順序啟動其它虛擬單板進程.流程示意如圖4-6.圖4-6流程示意圖4-6中主控進程啟動,根據(jù)配置啟動其它用戶進程參見圖4-7,根據(jù)配置依次啟動其它虛擬單板進程參見圖4-8.圖4-7主控進程控制單板上其它用戶進程順序啟動示意圖圖4-8 VOMP主控進程順序啟動其它虛擬單板進程示意圖圖4-7中主控進程給基本進程發(fā)送上電消息,等待應答,基本進程收到上電消息后進行初始化,完成后回送應答,這個過程可以調(diào)用VOS的同步消息接口完成.通信控制進程是主控進程第一個啟動的基本用戶進程

35、.4.5 工作原理 流程驅動部分負責執(zhí)行流程序列,包括驅動消息構建、消息發(fā)送、消息接收準備、消息比較、消息接收等一系列動作,處理通知消息等,具體的消息構建、發(fā)送、接收準備、比較、接收等一系列動作的執(zhí)行,由消息所屬的協(xié)議業(yè)務處理進程負責.驅動進程提供執(zhí)行框架,業(yè)務處理進程負責具體業(yè)務相關的處理.圖4.21以消息發(fā)送為例給出了子系統(tǒng)完整的工作序列圖,其中框中的都是用戶處理進程.其它消息接收準備、比較、接收是類似的.圖4-9 業(yè)務模擬子系統(tǒng)工作序列圖 1）Console的流程執(zhí)行控制臺將要執(zhí)行的用例流程數(shù)據(jù)轉化成XML,打包在Exe Req消息中根據(jù)一定的分發(fā)策略發(fā)給一個或者多個Tester中的模擬

36、流程控制 用戶進程.該分發(fā)策略下面將討論.Console和模擬流程控制用戶進程間的通 信,是由VOS提供的,對用戶透明,在VOS設計中已經(jīng)討論. 2）模擬流程控制收到Console的流程執(zhí)行控制臺發(fā)來的Exe Req消息,該消息 主要包括參數(shù)：執(zhí)行對象的XML表示數(shù)據(jù). 3）在流程驅動執(zhí)行過程中需要發(fā)送消息,找到消息對應的業(yè)務進程,向它發(fā)送 Build Req,采用同步消息接口. 4）業(yè)務處理進程收到Build Req請求后,處理自己的部分,如果還有其上層協(xié)議 消息需要處理,則向模擬流程控制發(fā)送Get Child Req,請求獲得其上層協(xié)議 消息. 5）模擬流程控制獲得其上層協(xié)議消息,回送Ge

37、t Child Res同步應答返回給業(yè) 務處理進程1. 6）業(yè)務處理進程1找到上層協(xié)議消息對應的業(yè)務進程,發(fā)送給業(yè)務進程2. 7）業(yè)務處理進程2處理完后,向業(yè)務處理進程1回送Build Res同步應答. 8）業(yè)務處理進程1收到業(yè)務處理進程2回送的Build Res同步應答后,將完整的 編碼后的碼流,通過同步應答B(yǎng)uild Res回送給模擬流程控制. 9）模擬流程控制獲得最終發(fā)送的碼流,向業(yè)務處理進程1發(fā)送異步消息Send Req 請求發(fā)送.4.6業(yè)務處理進程業(yè)務處理用戶進程的具體實現(xiàn)主要包括以下幾個方面： 1) 對消息構建、發(fā)送、接收準備、比較、接收等消息進行響應處理 2) 和信令處理進程交互

38、,發(fā)送和接收消息. 3) 對活動流程查詢消息進行相應 4) 向模擬流程控制進程發(fā)送通知消息.可見此測試工具的框架一旦穩(wěn)定下來,今 后所 做的工作主要是增加和完善業(yè)務處理進程.即增添相應的協(xié)議模塊,即 可實現(xiàn)對該協(xié)議消息的收發(fā).碼流分析子系統(tǒng)碼流分析子系統(tǒng)向用戶提供了實時觀察流程執(zhí)行情況,分析碼流收發(fā)的方法和手段： 1)當Console需要進行碼流分析時,通過配置對相應鏈路設置碼流分析的開關, 發(fā)送一條分析命令給這條鏈路所在邏輯地址對應單板上的業(yè)務處理用戶進程. 2）該進程收到執(zhí)行分析的指令后,注冊一個分析定時器,準備進行分析. 3）分析定時器時間到,對碼流緩沖區(qū)中的碼流進行分析,只分析出自己識

39、別的 部分,將分析出來的字符串、整個碼流、分析的位置信息以及時間戳等組裝 成一個分析消息包,發(fā)送給其上層協(xié)議業(yè)務處理進程進行分析,采用異步消息 接口. 4）上層業(yè)務處理進程根據(jù)碼流進行分析,如果還有上層協(xié)議業(yè)務處理進程,則 按照3）繼續(xù)處理. 5）最上層的業(yè)務處理進程分析完成后,將分析結果包括字符串以及完整碼流回 給其下層. 6）最下層獲得分析結果字符串和完整碼流,發(fā)給Console. 4.7 系統(tǒng)測試發(fā)現(xiàn)的部分故障 在系統(tǒng)測試中,公司內(nèi)部廣泛使用了此測試工具進行IMS域內(nèi)應用層協(xié)議測試,測試的網(wǎng)元主要有CSCF、PSS（PSTN/ISDN Simulation Service, PSTN/I

40、SDN 模擬服務器）、PDF（Policy Decision Function,策略決策功能）等等.在這些網(wǎng)元測試中測試人員使用此測試工具發(fā)現(xiàn)了大量的故障,實踐說明使用此專項的測試工具有助于測試工作的開展.下面結合具體實踐給出使用此測試工具進行IMS系統(tǒng)測試發(fā)現(xiàn)的部分故障予以說明.1） 待測試網(wǎng)元：PSS 測試步驟：使用測試工具模擬終端收發(fā)SIP消息2） 圖4-10基本呼叫流程預期結果：主被叫按照流程完成基本呼叫的信令建立媒體協(xié)商,進入通話態(tài).故障現(xiàn)象：PSS網(wǎng)元設置為支持資源預留（precondition）,主叫invite中sdp 和源預留相關的媒體部分的類型為e2e時,被叫側PSS網(wǎng)元對

41、SDP處理異常, 去除SDP后前轉消息,流程在Update處中止,PSS報500錯誤響應碼.定位為PSS 的協(xié)議模塊對e2e型的SDP解碼錯誤. 故障原因：在支持資源預留的sdp編解碼中在編碼中對mandatory拼寫錯誤,導致編碼出去的sdp再透傳到PSS解碼錯誤,協(xié)議層沒有將媒體報給業(yè)務層,媒體協(xié)商失敗. 2）待測試網(wǎng)元：PSS 測試步驟：使用測試工具模擬終端收發(fā)SIP消息,測試流程采用基本呼叫流程.其中主叫發(fā)送的invite消息攜帶Privacy頭部.主叫開通主叫號碼顯示限制（CLIR）業(yè)務. 預期結果：主叫側PSS使Privacy=id,被叫側PSS可以正常處理此頭部,可以建立基本呼叫

42、流程. 故障現(xiàn) 象：主叫開通CLIR業(yè)務且主叫發(fā)送的Invite中攜帶Privacy頭,如果主叫攜帶 的Privacy頭部為Privacy=none,則主叫側PSS添加Privacy=id,使Privacy=id;none,從而導致被叫側PSS處報協(xié)議錯400響應碼.如果主叫攜帶的Privacy頭部為Privacy=id,則主叫側PSS不做修改,流程可以走下去.如果主叫攜帶的Privacy頭部為Privacy=abc,則主叫側PSS添加Privacy=id,使Privacy=id;abc,流程同樣可以走下去.故障原因：當觸發(fā)CLIR業(yè)務時,主叫側PSS會添加 privacy:id頭,導致在none時,與其沖突. 3）待測試網(wǎng)元：PSS 測試步驟：使用測試工具模擬終端收發(fā)SIP消息,測試流程 采用基本呼叫流程,流程如圖4-10所示.被