第一篇：5.0版本RNC跟蹤CDT信令方法

1)、首先到OMU上修改RncTestConfig.xml文件。登陸到文件管理器上：

然后進入weblmt->version_x（主區(qū)，可通過LST OMUAREA查詢）->client->trace->resource下面。

找到RncTestConfig.xml文件，下載下來。

用文本格式打開，修改其中的L2和用戶面相關(guān)開關(guān)。

找到CDTMSGTYPE下的PARA參數(shù)，正常如下，我們需要將Value＝“0”的修改成1。

修改后如下，然后保存此文件。

返回到WebLMT文件管理器，將原有的RncTestConfig.xml文件刪除。

將修改后的RncTestConfig.xml文件上傳上去。

2、進入LMT跟蹤頁面，填寫IMSI，選擇DEBUG模式

Other選項里面勾選相關(guān)用戶面選項。

第二篇：跟蹤孔令學(xué)影評

有關(guān)孔令學(xué)

這是去年四月就上映的一部電影，以前聽說過，但是一直沒有去看。平時關(guān)注的多是國外的一些影片，對于本國的電影關(guān)注確實太少。相比國內(nèi)的大制作手筆，我更傾向于新生代導(dǎo)演用心制作的低成本電影，像是以前的《瘋狂的石頭》、《人在囧途》、《夜店》等等，雖稱不上是大家風(fēng)范的曠世奇作，但絕對可以稱得上是一道精美的小品。

看這部電影不是趨于偶然，而是最近看了第十放映室的新春特別節(jié)目，其中有一期就專門介紹也范偉這個演員。說實話，我看范偉的電影并不多《天下無賊》、《非誠勿擾》和《建黨偉業(yè)》。在以上電影里面，范偉都是以配角的身份出演的，戲份并不是很多，但其塑造的草根人物個性鮮明，總會給觀眾留下比較深刻的印象。在那期節(jié)目中，就提到了這部范偉主演的電影---《跟蹤孔令學(xué)》。

孔令學(xué)同樣的一個草根形象，在一所文武學(xué)校教授語文課的老師，雖然是地道的東北人，但是讀課文時，句句都是字正腔圓的普通話，從這邊可以體現(xiàn)出，孔老師的人物性格---做事認(rèn)真到位。他年近40，有老婆有孩子，家庭不能說很富裕，但是很和睦。他每天都是努力的工作，這又是一個典型的中年男人的形象。故事緣起于孔老師沒收了上課玩手機的一名同學(xué)的手機，這名同學(xué)是學(xué)校舞蹈班的一名女生劉萌，并且在這個過程中發(fā)生了一點肢體沖突。事后，劉萌名義上的男朋友阿祥，社會上開發(fā)廊的一個小混混，便找上了孔老師。他希望孔老師不要找劉萌的麻煩，但卻被孔老師拒之千里、閉口不談，甚至害怕阿祥會對自己的家人不利。但是阿祥依然是不依不饒的纏著孔老師，就這樣，一場跟蹤與反跟蹤的好戲上演了。剛開始的時候，感覺這部電影像是劇情片，雖然它以喜劇片標(biāo)簽，但是前30分鐘的劇情確實笑點不多；而中間30分鐘的時候，感覺它又像是一部懸疑驚悚電影，似乎有些時候連自己也不知道，這個阿祥到底是為了什么才這么一直跟著孔老師的；等看完最后30多分鐘的時候，終于發(fā)現(xiàn)，這部電影確實是一部喜劇電影，只不過是一部真正意義上的黑色喜劇，尤其是最后醫(yī)生為孔老師給出了診斷---焦慮癥。看完整部電影之后再看孔令學(xué)這個人物，當(dāng)然，范偉的塑造真的是無懈可擊，或許他真的對草根這樣的角色做到了信手拈來的程度，總之，這個人物已經(jīng)實體化了。他，孔令學(xué)就存在于我們的身邊。我給孔令學(xué)下的定義是百分之五十的孔子加百分之五十的孔乙己，最終就成為了孔令學(xué)。他對于自己的工作，對于自己的家庭都是盡職盡責(zé)，十分認(rèn)真，擁有一套自己的嚴(yán)格的道德規(guī)范，用醫(yī)生的話就是太認(rèn)真了；但是，他為人又顯得過分自我，過于偏激，對凡是有悖于自己道德的事情，又過于否定?？傊?，他是一個有著自己追求，但是卻容易受到外界影響的人。這種人有時候會活得很快樂，但是有時候會活得很累。在被跟蹤的期間，孔老師始終沒有給妻子說出事情的真相，而是變著花樣的編瞎話，希望能夠騙過妻子，但是孔老師的想法是好的，他這樣做也是為了不想讓妻子擔(dān)心。還有就是他始終沒能和阿祥做過一次真正的談話，或許在他的道德里面，這種人就是垃圾，根本不值得一談，即便是談，也不會得出什么結(jié)論，因為孔老師早把阿祥在心里面完全否定了。但是他又和劉萌講了手掌和拳頭的道理，希望能通過溝通得到劉萌的認(rèn)可，或許劉萌在他的眼中還是有藥可救的一個人吧。因此，我感覺，孔令學(xué)這個人物性格中存在的多面的矛盾體。其實我們每個人都是矛盾體的組成，只是在外界的刺激下，我們凸顯了其中的某一或者某些方面罷了?？琢顚W(xué)，是草根，他就生活在我們這些普普通通的人的身邊。而我們自己就或多或少的有著他的影子在身上。但我們真的應(yīng)該做些改變了，對什么事情，都要擁有一個平和的心態(tài)，做事情不要過于認(rèn)真，這不也是片中的醫(yī)囑嗎？

看到影片的結(jié)尾我的心里是暖和的，在孔令學(xué)上課的時候，有個男同學(xué)睡著了，這次他并沒有想影片開頭那樣處理問題，而是邊微笑著讀課文，邊把外套脫下來給那個同學(xué)蓋上。我想，他的所有心結(jié)至此已經(jīng)全部解開了吧。放平心態(tài)，正常面對，我們生存的社會就會多些和睦，溫暖，歡笑...^ ^

第三篇：運動目標(biāo)跟蹤方法

方法大致可以分為四類：基于區(qū)域匹配的跟蹤方法、基于模型的跟蹤方法、基 于動態(tài)輪廓的跟蹤方法和基于特征的跟蹤方法。

(1)基于區(qū)域匹配跟蹤方法的主要思想：該方法主要是將包含運動目標(biāo)的運動區(qū)域作為參考模板12引，在下一幀圖像中按照一定的搜索方法搜索模板，找 到的最優(yōu)搜索區(qū)域判定為匹配區(qū)域。該方法在理論上是十分有效，其可以獲得 豐富的目標(biāo)信息，對小目標(biāo)跟蹤效果好；但是當(dāng)搜索范圍較大時，目標(biāo)匹配會 花費大量的時間，而且如果目標(biāo)發(fā)生變化或者被遮擋時，跟蹤效果會大大下降。

(2)基于模型跟蹤方法的主要思想：該方法通常會使用三種模型進行目標(biāo)

跟蹤：線圖模型、2D模型、3D模型【231。在實際的應(yīng)用中，由于3D模型更接近現(xiàn)實生活中的物體，使用最多的是基于3D模型的跟蹤方法，特別是針對剛體(如 汽車、飛機等)的跟蹤。概括來說，跟蹤的方法如下：利用獲得的目標(biāo)3D模型，然后針對實際的視頻序列進行目標(biāo)的搜索與匹配。在實際的跟蹤環(huán)境中，3D模 型的運算量很大，而且獲得所有目標(biāo)的3D模型并全部存儲是一項幾乎不可能的 任務(wù)，因此該方法的實際應(yīng)用比較少。

(3)基于動態(tài)輪廓跟蹤方法的主要思想：該方法主要是指對目標(biāo)的輪廓進

行提取，即用一組封閉的輪廓曲線來描述目標(biāo)，將其作為匹配的模板。此輪廓 曲線能進行自我更新以適應(yīng)非剛體目標(biāo)的形狀變化12引。例如Paragan等人利用短 程線的輪廓，加入水平集理論檢測并跟蹤目標(biāo)【2 5J；最經(jīng)典的算法是Michael Kass 等人在1 988年提出的主動輪廓模型(即Snake模型)的方法【2 6|，其本質(zhì)是能量 的最小化。通過不斷求解輪廓曲線能量函數(shù)的最小值，不斷調(diào)整其形狀，從而 實現(xiàn)對目標(biāo)的跟蹤。該方法在簡單背景下，能夠準(zhǔn)確的進行目標(biāo)跟蹤。但其對 于背景復(fù)雜情況以及速度較快或形變較大的目標(biāo)，運算速度很慢，而且對于遮 擋問題的解決不是很好，因此很少應(yīng)用于實際的監(jiān)控系統(tǒng)中。

(4)基于特征的跟蹤方法的主要思想：該方法主要是通過提取目標(biāo)特定的特征集合，如角點或邊界線條等【2¨，將其作為跟蹤模板，在下一幀中搜索并進 行幀間的匹配，從而實現(xiàn)目標(biāo)的跟蹤1281。改算法的優(yōu)點在于其是以目標(biāo)特征為 基礎(chǔ)，因此，在目標(biāo)的整體特征不完整，即目標(biāo)被部分遮擋的情況下仍然可以 實現(xiàn)跟蹤。該方法是目前應(yīng)用最多的一種方法。

1．4．課題的研究內(nèi)容與論文結(jié)構(gòu)安排

運動目標(biāo)檢測與跟蹤是智能視頻監(jiān)控領(lǐng)域的基礎(chǔ)與前提。本文主要是針對 靜態(tài)場景下的運動目標(biāo)檢測與跟蹤，通過不斷的研究和學(xué)習(xí)，找到更好的運動 目標(biāo)檢測與跟蹤方法。

本文對目前常用的目標(biāo)檢測與跟蹤方法進行了原理介紹與性能分析，并在 前人的基礎(chǔ)上提出了自己的解決方案，且與原有的基于混合高斯模型的目標(biāo)檢 測方法以及基于基于碼本模型的目標(biāo)檢測進行了比較。在運動目標(biāo)跟蹤方面采 用基于Kalman預(yù)測的Mean Shift方法，同時加入了信息量度量的方法，使得

第四篇：七號信令總結(jié)

其號信令

通信網(wǎng)主要可以分為兩大部分：信令網(wǎng)和話路網(wǎng)，而信令網(wǎng)又是通信網(wǎng)絡(luò)中的基礎(chǔ)。在信令網(wǎng)中所運行的信令協(xié)議主要可分為：中國一號信令（隨路信令）和NO7信令（共路信令）。而在我國的通信網(wǎng)中主要使用NO7信令。NO7信令是整個通信網(wǎng)絡(luò)的基礎(chǔ)，我可以用這樣一個比喻來表達NO7信令的作用，如果將整個通信網(wǎng)絡(luò)的硬件設(shè)施比喻成一個人的骨架，那么NO7信令就是流淌在這個人身體中的血液。由此可知，NO7信令是貫穿于整個通信網(wǎng)絡(luò)的，它是為了完成呼叫接續(xù)的一種通信語言。NO7信令我們也可以說成是為了完成某種業(yè)務(wù)的操作交互而發(fā)出的一些指令或命令。

NO7信令有四種分類方式：按照傳送方向分可以分為前向信令和后向信令；按照功能分可以分為管理信令、線路信令？；按照工作區(qū)域分可以分為局間信令和用戶線信令；按照傳送信道分可以分為共路信令和隨路信令。下面我們重點介紹一下共路信令和隨路信令：隨路信令是指傳送信令的鏈路和話路是同一條鏈路；共路信令是指傳送信令的鏈路和話路不在同一條鏈路上。中國一號信令就是隨路信令，而NO7信令是共路信令。共路信令依據(jù)其自身的構(gòu)架而引發(fā)出了一些優(yōu)點：信令傳輸速度快；信令容量大；信道利用率高；信令易于管理和維護；易于開發(fā)一些基于信令的上層應(yīng)用。但有優(yōu)點的同時也給共路信令提出了一些特殊的要求：信道傳輸?shù)陌踩砸?；信道傳輸?shù)恼`碼率要低；話路通道要添加自身的監(jiān)聽功能，因為在共路信令系統(tǒng)中信令鏈路相通并不能代表著話路也是相通的。

上面主要講述了NO7信令的分類以及各自的特點。下面我們來具體描述一下NO7信令的基本概念：

1.信令鏈路（Link）：即指用來傳送信令的物理通道，一般為E1線的一個時隙；

2.信令鏈路集（LinkSet）：具有相同屬性鏈路的集合，也可以說成是到一個局向的所有鏈路組成的集合。同一個信令鏈路集中的所有鏈路是負(fù)荷分擔(dān)的。兩個信令點之間直連的鏈路集只能有一個；

3.信令鏈路編碼（SLC）、信令鏈路編碼發(fā)送（SLCS）和鏈路編號（Link NO）：信令鏈路編碼是用來區(qū)分同一個鏈路集中不同鏈路的；SLCS是在測試消息中所使用的，讓對方來識別同一鏈路集中的鏈路；而鏈路編號則是用來區(qū)分同一模塊中的不同鏈路的。同一條鏈路兩端的SLC必須一致，如果不一致鏈路則不會相通；鏈路一端的SLC和SLCS一般必須配成一致，如果不一致鏈路很可能不會相同的；

4.信令路由（RT）：即到達某一信令點的路徑；信令路由其有目的信令點和鏈路集組成的一個對應(yīng)關(guān)系。到達某一信令點可能有多條路由；

5.信令點編碼（SPC）：即指每個信令實體的編碼，該編碼相當(dāng)于該信令實體的地址，在具體的尋址過程中會被使用到。而信令點編碼依據(jù)其長度不同可以分為14位信令點和24位信令點。國際上一般采用14位信令點編碼，而國內(nèi)一般采用24位信令點編碼；具體的編碼結(jié)構(gòu)可以參看下圖：

接下來我們再介紹一下NO7網(wǎng)的基本概念。NO7信令網(wǎng)是我國通信網(wǎng)的基礎(chǔ)，它負(fù)責(zé)信令的交互以完成用戶的某項業(yè)務(wù)需求。而NO7信令網(wǎng)是由信令點、信令轉(zhuǎn)接點和信令鏈路組成的。下面就著重介紹一下這三要素：

1.信令點（SP）：即為信令網(wǎng)中發(fā)送或接收信令消息的實體。如果是發(fā)送信令消息，那

么就可以稱該信令點為源信令點；如果是接收信令消息，那么就可以稱該信令點為目的信令點；一般情況下，信令網(wǎng)中的每個信令點既為源信令點又為目的信令點；

2.信令轉(zhuǎn)接點（STP）：也是信令網(wǎng)中的一個實體，但它既不是信令源點也不是信令目的點，它只是將收到的消息轉(zhuǎn)發(fā)給另一個信令實體。

3.信令鏈路：該概念在前面已介紹過了，它在信令網(wǎng)中主要是負(fù)責(zé)連接不同信令點或信令轉(zhuǎn)接點，使其相互之間能夠貫通。至于信令網(wǎng)中的連接方式又可以分為兩種：直連方式和準(zhǔn)直連方式。直連方式即指兩個信令點直接相連，中間不經(jīng)過任何轉(zhuǎn)接；而準(zhǔn)直連方式是指兩個信令點間的連接是經(jīng)過一個或多個信令轉(zhuǎn)接點轉(zhuǎn)接的。因為信令轉(zhuǎn)接點對用戶傳輸來說是透明的，就如同直連，所以我們稱之為準(zhǔn)直連?，F(xiàn)網(wǎng)中的連接方式以準(zhǔn)直連方式居多；

再下來我們介紹一下我國NO7信令網(wǎng)的組成結(jié)構(gòu)，其結(jié)構(gòu)是比較清晰的，可以用兩句話來描述全網(wǎng)結(jié)構(gòu)：我國NO7信令網(wǎng)是三層架構(gòu)，采用雙平面結(jié)構(gòu)。其三層結(jié)構(gòu)分別為：高級信令轉(zhuǎn)接點HSTP（分布在各主要省分）、低級信令轉(zhuǎn)接點LSTP（分布在地級市）、信令點SP（又稱為端局，一般分布在地級縣）；而雙平面結(jié)構(gòu)主要是為了提高信令網(wǎng)的可靠性，我們一般采用A、B雙平面結(jié)構(gòu)，即HSTP一般都成對出現(xiàn)，并兩兩相連，這樣即使一個HSTP故障了，另外一個還可以接替。具體的結(jié)構(gòu)描述如下圖：

NO7信令的承載方式有三種，分別為：TDM、ATM和IP；其各自在承載層上有很大的不同，但這些不同對上層用戶來說是透明的。TDM和ATM我們稱為窄帶傳輸，而IP我們稱為寬帶傳輸；TDM和ATM需要時鐘，而IP不需要時鐘；TDM有兩種速度，一種為64K（E1線中的某一個時隙），另一種為2M（利用E1線中31個時隙）；ATM的速度為2M，使用E1線中30個時隙（0號時隙用于傳時鐘，16號時隙用于傳管理消息）；IP總帶寬為100M，依照其建立的鏈路數(shù)不同，其帶寬也相應(yīng)的不同。三種承載方式的層次結(jié)構(gòu)圖如下：

下面將詳細講解NO7信令的層次結(jié)構(gòu)，以及每層的作用。NO7信令的層次結(jié)構(gòu)圖如下：

我們HLR系統(tǒng)主要運用NO7信令的MAP協(xié)議層，其具體包含：MAP、TCAP、SCCP、MTP3、MTP2、MTP1。下面將詳細介紹這六層的作用以及在CPCI平臺的哪個模塊處理：

1.MTP1－信令數(shù)據(jù)鏈路層：對應(yīng)于OSI模型中的物理層。信令數(shù)據(jù)鏈路功能是MTP的第一功能級，定義信令數(shù)據(jù)鏈路的物理、電氣和功能特性。而信令數(shù)據(jù)鏈路又可分為數(shù)字信令數(shù)據(jù)鏈路和模擬信令數(shù)據(jù)鏈路。在數(shù)字信令數(shù)據(jù)鏈路中規(guī)定采用64Kb/s的速率（PCM群的一個時隙的傳輸速率）；在模擬信令數(shù)據(jù)鏈路中，如采用頻分復(fù)用傳輸系統(tǒng)的信令數(shù)據(jù)鏈路，規(guī)定采用

4.8Kb/s的速率。在我們移動通信網(wǎng)絡(luò)中，都采用數(shù)字信令數(shù)據(jù)鏈路。

MTP1層簡單的說它僅向MTP2提供了一個物理的通道，不對信令消息做任何處理。MTP1層在CPCI平臺的EPI板上處理，在32模平臺上是DTM板處理。

MTP1層就好像我們建立起的一條初始的公路，沒有安裝任何交通指示燈，也沒有標(biāo)明該條公路的去向。

在MTP1層上所具有的概念有：時隙、EPICFG、傳輸方式（例如DoubleFrame）。

2.MTP2－信令鏈路層：對應(yīng)于OSI模型中的數(shù)據(jù)鏈路層。信令鏈路功能主要是規(guī)定了為在兩個直接連接的信令點之間傳送信令消息提供可靠的信令鏈路所需要的功能。MTP2層的主要功能有：信令單元的收發(fā)控制和信令鏈路狀態(tài)監(jiān)視。信令單元的收發(fā)控制主要包括：信令單元的分界、信令單元的定位、信令單元的差錯檢測和信令單元的差錯校正。而信令鏈路狀態(tài)監(jiān)視主要包括：信令單元差錯率的監(jiān)視、處理機故障處理及信令鏈路故障處理和擁塞時的流量控制。MTP2層簡單的說它為上層用戶提供了一個可靠的邏輯通道，它對信令消息的內(nèi)容不作任何處理，只是在消息碼流中插入定位定界符和差錯校驗位。而這些插入的定位定界符和差錯校驗位對上層用戶來說是透明的，所以我們也可以說MTP2層對信令消息不做任何處理。MTP2層在CPCI平臺的CPC扣板處理，在32模平臺上是LAP板處理。

MTP2層就好像一條安裝了交通指示燈的公路，該公路上的車流有斷連和暢通的狀態(tài)。但該條公路還沒有標(biāo)明去向。

在MTP2層上所具有的概念有：鏈路、鏈路狀態(tài)（激活、去活）、SLC、SLCS、鏈路編號、鏈路的類別（TDM64K、TDM2M、MTP3BLNK、M3UALNK）、鏈路級別的流控。

3.MTP3－網(wǎng)絡(luò)層：該層和SCCP層一同對應(yīng)于OSI的網(wǎng)絡(luò)層。MTP2層保證了兩個直接連接的信令點之間傳送信令消息的可靠性，但它對信令消息不作任何處理（從用戶層面上看，其實MTP2層會向消息碼流中插入定位定界符和差錯校驗位），MTP3則是處理信令消息的最低一層。MTP3層在MTP2層的基礎(chǔ)上實現(xiàn)了信令網(wǎng)絡(luò)級別的功能，即具有路由尋址的功能。

MTP3層為整個信令網(wǎng)絡(luò)提供了路由尋址的功能，其在信令消息發(fā)送和接收過程中都起著重要的作用。MTP3層主要有兩大功能：信令消息處理和信令網(wǎng)絡(luò)管理。信令消息處理內(nèi)部又可以分為三大塊：消息識別、消息分配和消息編路。信令網(wǎng)絡(luò)管理主要可以分為：信令業(yè)務(wù)管理、信令路由管理、信令鏈路管理。根據(jù)上述的描述我們可以清楚的知曉MTP3的基本功能。

MTP3層就好像一條安裝了交通指示燈，同時也標(biāo)明了去向的公路。該公路上的車流不但有斷連和暢通的狀態(tài)，而且還有路由尋址的功能。

MTP3層所具有的概念有：目的信令點DSP、路由RT、鏈路集LKS、路由負(fù)荷分擔(dān)、鏈路負(fù)荷分擔(dān)、鏈路測試消息。

4.SCCP－信令連接控制層：和MTP3層一起對應(yīng)于OSI模型中的網(wǎng)絡(luò)層。信令連接控制部分的目的是加強消息傳遞部分（MTP）的功能，它和MTP3一起構(gòu)成NO7信令的網(wǎng)絡(luò)層，為信令在網(wǎng)絡(luò)中的傳輸提供網(wǎng)絡(luò)尋址轉(zhuǎn)發(fā)的能力。由于MTP的尋址功能僅限于向節(jié)點傳遞消息，只能提供無連接的消息傳遞功能，而SCCP則利用目的信令點編碼（DPC）和子系統(tǒng)（SSN）來提供一種尋址能力，用來識別節(jié)點中的每一個SCCP用戶；另外，由SCCP提供的另外一種尋址方式是全局碼（GT），從而彌補了MTP信令點編碼不具備全局性、網(wǎng)內(nèi)編碼容量有限、用戶過少的不足。SCCP的業(yè)務(wù)可以分為4類：0類為基本無連接類；1類為有序的無連接類；2類為基本面向連接類；3類為流量控制面向連接類。而我們在NO7信令系統(tǒng)中基本上使用0類SCCP消息。MTP層我們經(jīng)常說為承載層，如果將MTP層比喻成卡車，那么SCCP層就等同于電子地圖，它能幫助司機準(zhǔn)確定位去向。

SCCP層所具有的概念有：GT地址，GT翻譯，GT校驗，SSN尋址，UDT和XUDT消息，N_notice消息。

5.TCAP－事務(wù)處理能力子層：TC是由事務(wù)處理能力應(yīng)用部分（TCAP）及中間服務(wù)部分（ISP）兩部分組成。其中，TCAP的功能對應(yīng)于OSI的第7層，ISP對應(yīng)于OSI的第4-6層。目前NO7信令中的應(yīng)用都是基于無連接的TCAP層上的，沒有使用到ISP層。所以下面將詳細介紹一下TCAP層。

TCAP層將不同節(jié)點間的消息交互抽象為一個操作，TCAP的核心就是執(zhí)行遠程操作。TCAP消息的基本單元是成份（Component）。一個成份對應(yīng)于一個操作請求或響應(yīng)，一個消息中可以

包含多個成份。一個成份中包含的信息含義由TC用戶定義，相關(guān)的成份構(gòu)成一個對話，一個對話的過程可以實現(xiàn)某項應(yīng)用業(yè)務(wù)過程。

TCAP為了實現(xiàn)操作和對話的控制，分為兩個子層――成份子層（CSL）和事務(wù)處理子層（TSL），CSL主要進行操作管理，TSL主要進行事務(wù)（即對話）管理。TC用戶與CSL通過TCAP原語接口，CSL與TSL通過TR原語接口，TSL與SCCP層通過N原語接口聯(lián)系。其層次結(jié)構(gòu)如下圖：

事務(wù)處理子層（TSL）完成對本端成份子層用戶和遠端事務(wù)處理子層用戶之間通信過程的管理，事務(wù)處理用戶（TC用戶）目前唯一的就是成份子層（CSL），因此對于對等CSL用戶之間通信的對話與事務(wù)是一一對應(yīng)的。事務(wù)處理子層對對話的啟動、保持和終結(jié)進行管理，包括對話過程異常情況的檢測和處理。在TCAP協(xié)議中，對話分為兩大類――非結(jié)構(gòu)化對話和結(jié)構(gòu)化對話。具體描述如下：

??????????非結(jié)構(gòu)化對話是指TC用戶發(fā)送不期待回答的成份（第四類操作），沒有對話的開始、繼續(xù)和結(jié)束過程，在TCAP中利用單向消息發(fā)送；

??????????而結(jié)構(gòu)化對話必須指明對話的開始、繼續(xù)和結(jié)束。在兩個TC用戶間允許存在多個結(jié)構(gòu)對話，每個對話必須由一個特定的事務(wù)標(biāo)識號（TransactionID）標(biāo)識。同一個對話中可全雙工地交換成份，用戶在發(fā)送成份前指明對話的類型。對話的類型具體有四類：對話開始（Begin）、對話的繼續(xù)（Continue）、對話的結(jié)束（End）和對話中止（U_Abort和P_Abort）。

事務(wù)處理子層通過TR請求原語接受TC用戶經(jīng)成份子層發(fā)送的對話控制指示，生成指定類型的TCAP消息發(fā)往遠端；同時通過TR指示原語將接收到的TCAP消息中的數(shù)據(jù)（成份）傳送給成份子層。TCAP協(xié)議中定義了如下六種TR原語：TR_UNI（單向）、TR_BEGIN、TR_CONTINUE、TR_END、TR_U_ABORT和TR_P_ABORT。

成份處理子層（CSL）完成對話中成份的處理及對話的控制處理。事務(wù)處理子層負(fù)責(zé)傳送對話消息的基本單元就是成份。一個對話消息可以包含一個或多個成份（少數(shù)無成份，只起到對話控制作用），一個成份對應(yīng)于一個操作的執(zhí)行請求或操作的執(zhí)行結(jié)果。每個成份由不同的成份調(diào)用標(biāo)識號（Invoke ID）標(biāo)識，通過調(diào)用標(biāo)識號，控制多個相同或不同操作成份的并發(fā)執(zhí)行。操作的定義由具體的操作碼及參數(shù)標(biāo)識，由TC用戶定義，成份子層通過TC成份原語進行成份處理，以對話的形式請求相關(guān)于某一對話標(biāo)識的成份，將成份嵌入到對話與對話控制部分，通過TR原語發(fā)向?qū)Χ说腡CAP，因此成份子層分為成份處理和對話處理。

實際上，成份子層并部管理對話過程，它僅僅將TC用戶的對話控制信息傳送到事務(wù)處理子層，由事務(wù)處理子層完成對對話的控制。成份處理子層的TC原語包括成份處理原語和對話處理原語兩種。成。份對處話理處原理語原包語括包括以以下下96種種：：TC-INVOKE, TC-RESULT-L, TC-U-ERROR, TC-U-REJECT, TC-L-REJECT, TC-R-REJECT, TC-U-CANCLE, TC-L=CANCEL

TC-UNI, TC-BEGIN, TC-CONTINUE, TC-END, TC-U-ABORT, TC-P-ABORT。

TCAP消息由一個單構(gòu)成式信息單元組成，其包括事務(wù)處理子層的事務(wù)處理部分，與成份相關(guān)成份子層的成份部分及作為任選包含應(yīng)用上下文及用戶信息的對話控制部分。具體的TCAP消息結(jié)構(gòu)如下圖：

TCAP層所涉及的概念有：事務(wù)ID、OTID、DTID、InvokeID、OperationCode、對話或事務(wù)、DialogueID、TCAP協(xié)議狀態(tài)機。

6.MAP－移動應(yīng)用子層：對應(yīng)于OSI模型中的應(yīng)用層。MAP的功能主要是為通信網(wǎng)絡(luò)中各網(wǎng)絡(luò)實體之間完成移動臺的自動漫游功能而提供的一種信息交換方式。具體的MAP業(yè)務(wù)消息在TCAP消息中以成份形式存在，一般來講，MAP業(yè)務(wù)的消息類型和TCAP成份中的操作碼一一對應(yīng)，而在消息傳遞過程中，一個消息對應(yīng)一個調(diào)用識別（InvokeID），一個調(diào)用識別在其MAP對話過程中是對某個消息的唯一識別，通過區(qū)分調(diào)用識別，可以將一個成份“翻譯”成對應(yīng)的MAP業(yè)務(wù)消息，MAP與TCAP之間的消息轉(zhuǎn)換是由MAP協(xié)議狀態(tài)機（MAPPM）來完成的，此外協(xié)議狀態(tài)機還負(fù)責(zé)對話流程及操作流程的控制等功能。

MAP消息所涉及的TCAP對話處理原語有：TC-BEGIN、TC-END、TC-CONTINUE、TC-U-ABORT；所涉及的成份處理原語有：TC-Invoke（調(diào)用成份）、TC-Result（結(jié)果成份）、TC-Error（返回錯誤成份）、TC-Reject（拒絕成份）等。

MAP層所涉及的概念有：各類MAP消息（如位置更新、取路由、取鑒權(quán)集等）、DialogueID、MAP協(xié)議狀態(tài)機、MAP話統(tǒng)、MAP消息跟蹤。

我們列舉一個消息發(fā)送實例，來觀察消息是如何經(jīng)過各層次處理的以及了解各層次所做的操作。具體參看下圖：

上面所講述的正是我們信令數(shù)據(jù)配置的原理，下面我們將結(jié)合上述所介紹的信令數(shù)據(jù)配置原理來講解一下信令數(shù)據(jù)配置中的一些注意細節(jié)。

??????????SLC、SLCS、鏈路編號和時隙這四者的區(qū)別：

SLC（信令鏈路編碼）是用來區(qū)分同一鏈路集中的不同的鏈路；SLCS（信令鏈路編碼發(fā)送）主要用來填充在測試消息中，讓對端來區(qū)分同一鏈路集中的鏈路的；鏈路編號一方面是用來區(qū)分同一模塊下的鏈路，另一方面還與WCSU上的上下CPC扣板相關(guān)聯(lián)，鏈路編號從0到15是在下CPC扣板處理，而鏈路編號從16到31則是在上CPC扣板處理；時隙這是物理層上的概念，我們的TDM和ATM承載方式都是使用的時分復(fù)用的原理，將一條E1線劃分為32個時隙，每個時隙的速度為64Kb/s。另外時隙和鏈路編號還有一定的對應(yīng)關(guān)系，即時隙號從0到127的鏈路編號范圍為0~15,而時隙號從128到255的鏈路編號范圍為16~31。

??????????路由的負(fù)荷分擔(dān)和鏈路的負(fù)荷分擔(dān)原理：

路由的負(fù)荷分擔(dān)和鏈路的負(fù)荷分擔(dān)的原理是一樣的，都是利用SLS和掩碼經(jīng)過負(fù)荷分擔(dān)算法進行計算得到的選擇的路由或鏈路。路由選擇的掩碼是在MTP目的信令點表中（N7DSP或MTP3BDSP或M3DE），而鏈路選擇的掩碼是在鏈路集表中（N7LKS或MTP3BLKS或M3LKS）。具體的負(fù)荷分擔(dān)算法的原理如下：

??????????SSN：

SSN子系統(tǒng)也是尋址中的一部分，它是在一個信令實體內(nèi)部以SSN來進一步尋址，主要是用來確定是該信令實體中的哪個子系統(tǒng)（例如MSC和VLR就是同一個信令實體，但它們卻有著不同的子系統(tǒng)）。至于SSN的作用，就要分上行消息和下行消息來描述：上行消息時，當(dāng)經(jīng)過DPC校驗和GT校驗后，會進行SSN尋址，即觀察消息中所攜帶被叫地址中的SSN是否可用（這里的檢測SSN是否可用的方法，即以消息中的DPC來作為DPC和OPC查詢SCCPSSN表，看是否存在相應(yīng)的SSN，然后再檢測其狀態(tài)）；下行消息時，當(dāng)經(jīng)過GT翻譯后，我們會校驗DPC是否配置、狀態(tài)是否可及，然后就會校驗SSN是否配置、狀態(tài)是否可及，如果都可及，那么就會將消息下發(fā)到MTP層進行進一步尋址。注意一點，下行消息中的SSN雖然是在MAP層已被指定，但在SCCP層中也有可能更改，即如果GT翻譯結(jié)果中含有SSN，那么就會將消息中的SSN替換成GT翻譯所得的SSN。

??????????GT地址翻譯表的配置方法：

配置GT地址翻譯表有兩個原則：一，兩個相鄰的實體，其GT翻譯結(jié)果類型一般為DPC或DPC＋SSN。兩個不相鄰的實體，其GT翻譯結(jié)果類型一般為DPC+old GT或DPC+new GT；二，自身的GT翻譯類型一般為DPC或DPC+SSN，以免在GT校驗時發(fā)生循環(huán)，導(dǎo)致消息落不了地； ??????????STP轉(zhuǎn)接的配置方法：

STP轉(zhuǎn)接的配置方法有兩種：一，MTP層轉(zhuǎn)接，即使接收到的消息在MTP層校驗DPC失敗，失敗后系統(tǒng)會嘗試以該DPC重新尋址，將該消息轉(zhuǎn)發(fā)出去（前提是該信令點有STP功能）；二，SCCP層轉(zhuǎn)接，即使收到的消息在SCCP層校驗GT失敗，被叫地址中的GT翻譯后所得的DPC和系統(tǒng)的SPC不同，此時系統(tǒng)會嘗試以該GT翻譯后的DPC來重新尋址，將該消息轉(zhuǎn)發(fā)出去（前提是該信令點有STP功能）；

第五篇：深圳聯(lián)通第三方測試保障后臺信令跟蹤分析過程總結(jié)V1.0

第三方測試保障后臺信令跟蹤分析過程V1.0

目錄1軟件工具使用................................................................................................................................3

1.1 后臺信令抓取...........................................................................................................3

1.1.1 后臺信令抓取任務(wù)設(shè)置和過程.......................................................................3 1.1.2 后臺信令保存...................................................................................................4 1.2 信令文件處理工具...................................................................................................4

1.2.1 信令文件處理工具包.......................................................................................4 1.2.2 生成文件內(nèi)容簡介...........................................................................................5 1.3 PS業(yè)務(wù)速率統(tǒng)計................................................................................................................5 2 數(shù)據(jù)統(tǒng)計分析...........................................................................................................................7

2.1 測試號碼業(yè)務(wù)定位...................................................................................................7

2.1.1 判斷業(yè)務(wù)速率...................................................................................................7 2.1.2 判斷業(yè)務(wù)主被叫...............................................................................................8 2.2 呼叫次數(shù)統(tǒng)計...........................................................................................................8

2.2.1 CS業(yè)務(wù)呼叫次數(shù)統(tǒng)計方式..............................................................................8

2.2.1.1 主叫相關(guān)次數(shù)統(tǒng)計...................................................................................8 2.2.1.2 被叫相關(guān)次數(shù)統(tǒng)計.................................................................................10 2.2.2 PS業(yè)務(wù)撥號相關(guān)次數(shù)統(tǒng)計方式....................................................................11 2.3 呼損分析.................................................................................................................12 2.3.1 主叫呼損分析.................................................................................................12 2.3.2 被叫引起呼損分析.........................................................................................12 2.3.3 呼損案例分析.................................................................................................13 2.4 掉話分析.................................................................................................................14 2.4.1 CS業(yè)務(wù)掉話分析............................................................................................14 2.4.2 PS業(yè)務(wù)掉話分析............................................................................................14 2.5 注意事項.................................................................................................................14 2.5.1 IMSIDetachIndication異常.............................................................................14 2.5.2 跨Iur口切換造成信令流程不完整..............................................................14 2.5.3 2-3G互操作....................................................................................................14

1軟件工具使用

1.1 后臺信令抓取

1.1.1 后臺信令抓取任務(wù)設(shè)置和過程

本次深圳聯(lián)通第三方測試主要在關(guān)內(nèi)的8個RNC下測試，在信令跟蹤Debug模式下，跟蹤第三方測試的不同用戶的RNLC_UE SIGNAL BY UEID任務(wù)信令。首先在信令跟蹤工具啟動需要跟蹤的RNC傳輸網(wǎng)絡(luò)層的連接: 選擇文件->連接，在彈出的對話框中選擇或添加RNC的服務(wù)器名稱，ip地址以及端口號：

然后跟蹤用戶IMSI，過程如下：選擇任務(wù)管理->創(chuàng)建RNL任務(wù)，填寫任務(wù)名稱，選擇任務(wù)類型為：RNLC_UE SIGNAL BY UEID信令：

再在任務(wù)詳細設(shè)置中填寫IMSI號，勾選所有選項。

1.1.2 后臺信令保存

深圳聯(lián)通信令數(shù)據(jù)保存時間分上下午保存，分別保存.std格式和.txt格式。

注：因為后續(xù)批處理工具需要使用.txt文檔的格式的碼流，.Std格式的碼流也需要抓取，用于后期詳細分析使用。

1.2 信令文件處理工具 1.2.1 信令文件處理工具包

該工具包包括UESigStat.exe和UESig.bat，同時需要站點信息列表索引文件。

其中站點信息索引文件需要放在C盤根目錄下，即C：，使用文本編輯軟件（UEdit、Notepad等）打開來編輯。里面的數(shù)據(jù)以“cellid = 23 cellname = 金華新聯(lián)通-3”的格式來添加。

通過后臺信令抓取工具SignalTraceTool抓取信令后，需要保存1個或若干個*.txt的信令碼流文件，然后把start.bat、UESigStat.exe放到和該信令碼流同目錄下，右鍵單擊start.bat點編輯，再在文本中UESigStat命令的后面添加上需要處理的若干個碼流文件名即可（如果添加了不存在的文件名，運行時也會跳過，不影響其他文本的生成）。舉例如下： A：抓取信令后，需要保存1個或若干個*.txt的信令碼流文件，然后把start.bat、UESigStat.exe放到和該信令碼流同目錄下；

B：可以對Uesig.bat進行編輯，目的是在文本中UESigStat命令的后面添加上需要處理的若干個碼流文件名：

C：運行Uesig.bat，就可以在當(dāng)前目錄生成名稱為之對應(yīng)的多個*.txt，Report.txt的文本文件：

1.2.2 生成文件內(nèi)容簡介

附生成的*.txt，Report.txt文本：

生成的文本大致分為4部分：

1部分：為信令計數(shù)器列表，列舉了流程中所有可能出現(xiàn)的信令并計數(shù)。對分析失敗所處的流程有很大的參考意義。

2部分：

為業(yè)務(wù)計數(shù)器列表，主要統(tǒng)計了該信令中各類業(yè)務(wù)主被叫成功和失敗次數(shù)，其中Unkown為部分特殊信令流程，如注冊、位置區(qū)更新等，需要在實際信令中確認(rèn)。

3部分：為每一次完整呼叫流程的關(guān)鍵信令，同時包括了信令的時間、方向、小區(qū)信息、時延等信息，對發(fā)現(xiàn)異常后的定位有很大幫助。

4部分：為跑車路線。

1.3 PS業(yè)務(wù)速率統(tǒng)計

PS業(yè)務(wù)后，需要在RNC端對前臺速率進行評估，這里需要使用后臺信令保存后的std格式文件。顯示如下：

導(dǎo)入std格式碼流文件：

顯示速率相關(guān)信息：

生成名稱為RateRecord.csv的文件是按照一分鐘粒度進行采用，表中給出了每次采用的時間和速率：

在本次第三方測試中統(tǒng)計PS業(yè)務(wù)的速率的平均值，以及采樣次數(shù)。數(shù)據(jù)統(tǒng)計分析

2.1 測試號碼業(yè)務(wù)定位 2.1.1 判斷業(yè)務(wù)速率

有2種方式可以看業(yè)務(wù)速率： 第一種：通過RAB_AssignmentRequestMsg信令中rAB_Parameters.maxBitrate.elem[0] = 64000

可以取得該業(yè)務(wù)上下行指派速率。

第二種：通過IuupSetupReq信令中的消息如下行的dwUlAssignedBitRate = 5760000可以取得該USIM的簽約速率。

2.1.2 判斷業(yè)務(wù)主被叫

業(yè)務(wù)建立起來后，通過rrcConnectionRequest信令中establishmentCause = terminatingConversationalCall可以判斷該業(yè)務(wù)是主叫還是被叫。

對于CS主叫業(yè)務(wù)，可以通過安全模式結(jié)束后第一個DirectTransfer（Setup）中的Numbering plan identification=***獲取被叫的號碼，從而方便將主被叫配對。

2.2 呼叫次數(shù)統(tǒng)計

2.2.1 CS業(yè)務(wù)呼叫次數(shù)統(tǒng)計方式

CS業(yè)務(wù)包括CS12.2K業(yè)務(wù)和CS64K業(yè)務(wù)，這兩種業(yè)務(wù)在業(yè)務(wù)建立的時候所進過的信令流程相同，因此呼叫次數(shù)統(tǒng)計方式也相同。

2.2.1.1 主叫相關(guān)次數(shù)統(tǒng)計

CS業(yè)務(wù)主叫呼叫包含如下信令，在第三方測試中，通常以RRC Connection Request到Alerting的信令流程為正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一個流程信令不完整而導(dǎo)致整個起呼信令不完整都可能認(rèn)為是一次起呼失敗。

UENodeBRNCCN(1)UL-CCCH:RRC Connection Request(originatingConversationalCall)(2)C_NBAP:Rdaio Link Setup Request(3)C_NBAP:Radio Link Setup Response(4)ALCAP:ERQ(5)ALCAP:ECF(6)DL_CCCH:RRC Connection Setup(7)UL_DCCH:RRC Connection Setup Complete(8)D_NBAP:Radio Link Restore Indication(9)UL_DCCH:Initial Direct Transfer(CM Service Request)(10)Initial UE Message(CM Service Request)(11)Direct Transfer(12)DL_DCCH:Downlink Direct Transfer(CM Service Accept)(13)UL_DCCH:Uplink Direct Transfer(Call Setup)(15)D_NBAP:Radio Link Reconfiguration Prepare(16)D:NBAP Radio Link Reconfiguration Ready(17)ALCAP:ERQ(18)ALCAP:ECF(19)D_NBAP:Radio Link Reconfiguration Commit(20)DL_DCCH:Radio Bearer Setup(21)UL_DCCH:Radio Bearer Setup Complete(22)RAB Assignment Response(23)DL_DCCH:Downlink Direct Transfer(Call Proceeding)(24)DL_DCCH:Downlink Direct Transfer(Alerting)(25)DL_DCCH:Downlink Direct Transfer(Connect)(26)UL_DCCH:Uplink Direct Transfer(Connect Acknowledge)(27)Direct Transfer(Connect Acknowledge)(14)RAB Assginment Request(Establishment)(CM Service Accept)步驟1：獲取主叫起呼次數(shù)

首先可以由信令處理軟件生成的Report.txt中以下內(nèi)容確認(rèn)主叫次數(shù)（MOSucc+MOFail=158+1），可以得到初步的起呼次數(shù)

# MO Succ = 158 MO Fail =1 MT Succ = 158 MT Fail = 1 PS Succ = 0 PS Fail = 0

Unkown = 1

#

步驟2：獲取主叫業(yè)務(wù)建立成功次數(shù)

由文本中MOSucc的計數(shù)可以得出主叫建立成功的次數(shù)。

步驟3：獲取主叫建立失敗次數(shù)

由文本中MOFail可以進一步判斷主叫建立失敗次數(shù)。（由于軟件將Connect DL被叫接聽的信令作為呼叫成功的依據(jù)，但如Alerting DL后被叫未及時接聽或掛斷，也判斷為一次建立失敗，但此時應(yīng)該根據(jù)實際情況來處理。）

通過上述2個步驟可以初步得出主叫建立失敗次數(shù)，但仍然需要對出現(xiàn)異常的信令進行分析，以進一步判斷是否是符合測試規(guī)范中定義的呼損。

2.2.1.2 被叫相關(guān)次數(shù)統(tǒng)計

CS業(yè)務(wù)被叫包含如下信令，在第三方測試中，通常以RRC Connection Request到Alerting的信令流程為正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一個流程信令不完整而導(dǎo)致整個起呼信令不完整都可能認(rèn)為是一次起呼失敗。

UENodeBRNC（1）PagingCN（2)DL_CCCH：Paging Type 1(3)UL-CCCH:RRC Connection Request(4)C_NBAP:Rdaio Link Setup Request(5)C_NBAP:Radio Link Setup Response(6)ALCAP:ERQ(7)ALCAP:ECF(8)DCCH_FP:Downlink SYNC(9)DCCH_FP:Uplink SYNC(10)DL_CCCH:RRC Connection Setup(11)UL_DCCH:RRC Connection Setup Complete(12)D_NBAP:Radio Link Restore Indication(13)UL_DCCH:Initial Direct Transfer（Paging Response）（16）DL_DCCH:Downlink Direct Transfer（Call Setup）（17））DL_DCCH:Uplink Direct Transfer（Call Confirmed)(14)Initial UE Message(PagingResponse)(15)Direct Transfer（Call Setup）(18)RAB Assignment Request(Establish)(18)D_NBAP:Radio Link Reconfiguration Prepare(19)D:NBAP Radio Link Reconfiguration Ready(20)ALCAP:ERQ(21)ALCAP:ECF(22)DTCH_FP:Downlink SYNC(23)DTCH_FP:Uplink SYNC(24)D_NBAP:Radio Link Reconfiguration Commit(25)DL_DCCH:Radio Bearer Setup(26)UL_DCCH:Radio Bearer Setup Complete(27)RAB AssignmentResponse(29)Direct Transfer(Alerting)(31)Direct Transfer(Connect)(32)Direct Transfer(Connect Acknowledge)(28)UL_DCCH:Downlink Direct Transfer(Alerting)(30)UL_DCCH:Downlink Direct Transfer(Connect)(33)DL_DCCH:Uplink Direct Transfer(Connect Acknowledge)

步驟1：獲取被叫尋呼到次數(shù)

首先可以由信令處理軟件生成的Report.txt文本中以下內(nèi)容確認(rèn)被叫次數(shù)（MTSucc+MTFail），可以得到初步的被叫次數(shù)：

# MO Succ = 158 MO Fail =1 MT Succ = 158 MT Fail = 1 PS Succ = 0 PS Fail = 0

Unkown = 1

#

步驟2：獲取被叫業(yè)務(wù)建立成功次數(shù)

由文本中MTSucc的計數(shù)可以得出被叫建立成功的次數(shù)。

步驟3：獲取被叫建立失敗次數(shù)

由生成的文本中MTFail可以進一步判斷被叫建立失敗次數(shù)。（由于軟件將Connect UL被叫接聽的信令作為成功的依據(jù)，但如Alerting UL后被叫未及時接聽或掛斷，也判斷為一次建立失敗，但此時應(yīng)該根據(jù)實際情況來處理。）

通過上述2個步驟可以初步得出被叫建立失敗次數(shù)，但仍然需要對出現(xiàn)異常的信令進行分析，以進一步判斷是否是符合測試規(guī)范中定義的呼損。

2.2.2 PS業(yè)務(wù)撥號相關(guān)次數(shù)統(tǒng)計方式

測試中PS業(yè)務(wù)沒有主被叫之分，因此只需要判斷PS業(yè)務(wù)起呼次數(shù)。由于測試中可能下載完成導(dǎo)致轉(zhuǎn)Idle，再回來時候是不需要重新?lián)芴枺虼酥恍枰y(tǒng)計PDP激活的次數(shù)。PS業(yè)務(wù)撥號相關(guān)流程如下圖：

UENodeB(1)UL_DCCH:Uplink Direct Transfer(ACT.PDP Context Req)RNCCN(2)Direct Transfer(ACT.PDP Context Req)(3)RAB Assginment Request(Establishment)(4)D_NBAP:Radio Link Reconfiguration Prepare(5)D:NBAP Radio Link Reconfiguration Ready(6)ALCAP-ERQ(7)ALCAP-ECF(8)DTCH_FP:Downlink SYNC(9)DCCH_FP:Uplink SYNC(10)D_NBAP:Radio Link Reconfiguration Commit(11)DL_DCCH:Radio Bearer Setup(12)UL_DCCH:Radio Bearer Setup Complete(13)RAB Assignment Response(14)Direct Transfer(15)DL_DCCH:Downlink Direct Transfer(ACT.PDP Context Accept)(ACT.PDP Context Accept)

步驟1：獲取撥叫次數(shù)

首先可以由信令處理軟件生成的Report.txt文本中以下內(nèi)容確認(rèn)撥叫次數(shù)（PSSucc+PSFail），可以得到初步的撥號次數(shù)：

# MO Succ = 158 MO Fail =1 MT Succ = 158 MT Fail = 1 PS Succ = 5 PS Fail = 0

Unkown = 1

#

步驟2：獲取撥叫成功次數(shù)

由生成的文本中PSSucc的計數(shù)可以得出撥號建立成功的次數(shù)。

步驟3：獲取撥叫失敗次數(shù)

由生成文本中PSFail的技術(shù)可以得出撥號建立失敗的次數(shù)。

2.3 呼損分析 2.3.1 主叫呼損分析

確認(rèn)主叫起呼的次數(shù)，可以通過rrcConnectionRequest、LocationUpdateReques和CMServiceRequest三條信令個數(shù)的關(guān)系來判斷，如果rrcConnectionRequest = LocationUpdateRequest + CMServiceRequest，則可以判斷RRC建立階段沒有失敗，起呼次數(shù)為CMServiceRequest的個數(shù)。如果上式不滿足，則可以認(rèn)為RRC建立階段出現(xiàn)呼損，需要到具體信令中定位（這一步需要根據(jù)實際規(guī)范看是否算在業(yè)務(wù)呼損里）。

其次可以進一步判斷，通過CMServiceRequest、CallProceeding、Connect DL三條信令個數(shù)的關(guān)系可以判斷呼損位置，如果CMServiceRequest=CallProceeding=Connect DL，則可以判斷業(yè)務(wù)建立階段沒有失敗，建立成功次數(shù)為Alerting DL。如果CMServiceRequest＞CallProceeding，則可能在RAB指派階段產(chǎn)生了異常；如果CallProceeding＞Connect DL，有可能是被叫切換到了其他RNC或發(fā)生了2-3G互操作。具體異常需要到具體信令中定位。

2.3.2 被叫引起呼損分析

其次可以進一步判斷被叫尋呼到的次數(shù)，可以分別通過rrcConnectionRequest、LocationUpdateReques和PagingResponse三條信令個數(shù)的關(guān)系來判斷，如果rrcConnectionRequest = LocationUpdateRequest + PagingResponse，則可以判斷RRC建立階段沒有失敗，被叫尋呼到次數(shù)為PagingResponse的個數(shù)。如果上式不滿足，則可以認(rèn)為RRC建立階段出現(xiàn)呼損，需要到具體信令中定位（這一步需要根據(jù)實際規(guī)范看是否算在業(yè)務(wù)呼損里）。

其次可以進一步通過PagingResponse、CallConfirm、Connect UL三條信令個數(shù)的關(guān)系可以判斷是否有呼損，如果PagingResponse=CallConfirm= Connect UL，則可以判斷業(yè)務(wù)建立階

段沒有失敗，建立成功次數(shù)為Connect UL。如果PagingResponse＞CallConfirm，則可能在其中階段產(chǎn)生了異常；如果CallConfirm大于Connect UL，則可能在業(yè)務(wù)建立產(chǎn)生了異常。具體異常需要到具體信令中定位。

2.3.3 呼損案例分析

以這次測試中的某一次呼損為例（這是一個2G呼3G的IMSI），下面給出初步的定位呼損原因的分析方法：

在生成的report.txt中的統(tǒng)計MO fail的次數(shù)可以認(rèn)為是在這個RNC下此次導(dǎo)出的數(shù)據(jù)中可能出現(xiàn)呼損的次數(shù)

# MO Succ = 3 MO Fail = 0 MT Succ = 1 MT Fail = 1 PS Succ = 0 PS Fail = 0

Unkown = 6

# 再在這個文本文件中找到相關(guān)的呼損記錄中的起呼流程如下，從該流程可以看出本次fail是被叫，在被叫振鈴8s后發(fā)起了一個disconnect，為什么會disconnect呢？

根據(jù)時間點再到信令中去分析是哪里出了問題，從這條消息中我們可以看到disconnect的原因為user busy，從而可以認(rèn)為此次呼損是因為被叫用戶因為繁忙而釋放此次連接。

2.4 掉話分析 2.4.1 CS業(yè)務(wù)掉話分析

對CS業(yè)務(wù)來說，查找是否有Iu_ReleaseRequestMsg，如果有，一般為掉話，此時可以查看原信令文件查看相關(guān)信令流程，定位問題。

2.4.2 PS業(yè)務(wù)掉話分析

對PS業(yè)務(wù)來說，查找是否有Iu_ReleaseRequestMsg，如果存在，則在原信令中查找到該Iu_ReleaseRequestMsg信令，看其cause.u.radioNetwork，判斷過程如下：

? 如果Cause值為TRANAP_user_inactivity，則PS業(yè)務(wù)為轉(zhuǎn)空閑過程，不算掉話。

? 如果Cause為其余值，則查看下一次rrcConnectionRequest后的第一次呼叫中是否存在PDPActiveRequest，如果有，說明下次業(yè)務(wù)建立為新的撥號，則上次Iu釋放為掉話。? 根據(jù)Cause值和其余相關(guān)信息定位此次PS業(yè)務(wù)掉話原因。

2.5 注意事項

2.5.1 IMSIDetachIndication異常

在測試過程中，PS業(yè)務(wù)可能會出現(xiàn)IMSIDetach的情況，該情況是由于數(shù)據(jù)卡或終端硬件異常導(dǎo)致，不能算為一種掉話。但在前面用生成的.t統(tǒng)計過程中會認(rèn)為這是掉話。需要將這類失敗去掉。

2.5.2 跨Iur口切換造成信令流程不完整

在測試過程中，跨Iur口切換業(yè)務(wù)可能會導(dǎo)致本RNC內(nèi)信令流程不完整，從而影響掉話原因的分析，同時還可能造成在本RNC下主被叫呼叫次數(shù)的不一致。此時需要將跨Iur口前后的2個數(shù)據(jù)綜合分析，排除異常。

2.5.3 2-3G互操作

在測試過程中，有可能會出現(xiàn)23G互操作的情況，如果被叫到了2G從而被主叫尋呼到，則在RNC的統(tǒng)計中會少了這次被叫的建立成功，因此需要通過cellChangeOrderFromUTRAN或handoverFromUTRANCommand_GSM信令查看是否發(fā)生了23G互操作，從而定位呼叫是否成功，尋呼是否成功。23G互操作也可能造成其他方面的統(tǒng)計問題(這種情況暫時還未遇到)