第一篇：5.0版本RNC跟蹤C(jī)DT信令方法

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

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

找到RncTestConfig.xml文件，下載下來(lái)。

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

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

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

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

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

2、進(jìn)入LMT跟蹤頁(yè)面，填寫(xiě)IMSI，選擇DEBUG模式

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

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

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

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

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

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

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

第三篇：運(yùn)動(dòng)目標(biāo)跟蹤方法

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

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

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

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

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

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

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

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

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

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

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

其號(hào)信令

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

NO7信令有四種分類方式：按照傳送方向分可以分為前向信令和后向信令；按照功能分可以分為管理信令、線路信令？；按照工作區(qū)域分可以分為局間信令和用戶線信令；按照傳送信道分可以分為共路信令和隨路信令。下面我們重點(diǎn)介紹一下共路信令和隨路信令：隨路信令是指?jìng)魉托帕畹逆溌泛驮捖肥峭粭l鏈路；共路信令是指?jìng)魉托帕畹逆溌泛驮捖凡辉谕粭l鏈路上。中國(guó)一號(hào)信令就是隨路信令，而NO7信令是共路信令。共路信令依據(jù)其自身的構(gòu)架而引發(fā)出了一些優(yōu)點(diǎn)：信令傳輸速度快；信令容量大；信道利用率高；信令易于管理和維護(hù)；易于開(kāi)發(fā)一些基于信令的上層應(yīng)用。但有優(yōu)點(diǎn)的同時(shí)也給共路信令提出了一些特殊的要求：信道傳輸?shù)陌踩砸撸恍诺纻鬏數(shù)恼`碼率要低；話路通道要添加自身的監(jiān)聽(tīng)功能，因?yàn)樵诠猜沸帕钕到y(tǒng)中信令鏈路相通并不能代表著話路也是相通的。

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

1.信令鏈路（Link）：即指用來(lái)傳送信令的物理通道，一般為E1線的一個(gè)時(shí)隙；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MTP1層簡(jiǎn)單的說(shuō)它僅向MTP2提供了一個(gè)物理的通道，不對(duì)信令消息做任何處理。MTP1層在CPCI平臺(tái)的EPI板上處理，在32模平臺(tái)上是DTM板處理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實(shí)際上，成份子層并部管理對(duì)話過(guò)程，它僅僅將TC用戶的對(duì)話控制信息傳送到事務(wù)處理子層，由事務(wù)處理子層完成對(duì)對(duì)話的控制。成份處理子層的TC原語(yǔ)包括成份處理原語(yǔ)和對(duì)話處理原語(yǔ)兩種。成。份對(duì)處話理處原理語(yǔ)原包語(yǔ)括包括以以下下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è)單構(gòu)成式信息單元組成，其包括事務(wù)處理子層的事務(wù)處理部分，與成份相關(guān)成份子層的成份部分及作為任選包含應(yīng)用上下文及用戶信息的對(duì)話控制部分。具體的TCAP消息結(jié)構(gòu)如下圖：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三方測(cè)試保障后臺(tái)信令跟蹤分析過(guò)程V1.0

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

1.1 后臺(tái)信令抓取...........................................................................................................3

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

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

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

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

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

2.2.1.1 主叫相關(guān)次數(shù)統(tǒng)計(jì)...................................................................................8 2.2.1.2 被叫相關(guān)次數(shù)統(tǒng)計(jì).................................................................................10 2.2.2 PS業(yè)務(wù)撥號(hào)相關(guān)次數(shù)統(tǒng)計(jì)方式....................................................................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 注意事項(xiàng).................................................................................................................14 2.5.1 IMSIDetachIndication異常.............................................................................14 2.5.2 跨Iur口切換造成信令流程不完整..............................................................14 2.5.3 2-3G互操作....................................................................................................14

1軟件工具使用

1.1 后臺(tái)信令抓取

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

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

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

再在任務(wù)詳細(xì)設(shè)置中填寫(xiě)IMSI號(hào)，勾選所有選項(xiàng)。

1.1.2 后臺(tái)信令保存

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

注：因?yàn)楹罄m(xù)批處理工具需要使用.txt文檔的格式的碼流，.Std格式的碼流也需要抓取，用于后期詳細(xì)分析使用。

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

該工具包包括UESigStat.exe和UESig.bat，同時(shí)需要站點(diǎn)信息列表索引文件。

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

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

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

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

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

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

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

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

2部分：

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

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

4部分：為跑車(chē)路線。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CS業(yè)務(wù)主叫呼叫包含如下信令，在第三方測(cè)試中，通常以RRC Connection Request到Alerting的信令流程為正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一個(gè)流程信令不完整而導(dǎo)致整個(gè)起呼信令不完整都可能認(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的計(jì)數(shù)可以得出主叫建立成功的次數(shù)。

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

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

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

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

CS業(yè)務(wù)被叫包含如下信令，在第三方測(cè)試中，通常以RRC Connection Request到Alerting的信令流程為正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一個(gè)流程信令不完整而導(dǎo)致整個(gè)起呼信令不完整都可能認(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的計(jì)數(shù)可以得出被叫建立成功的次數(shù)。

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

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

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

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

測(cè)試中PS業(yè)務(wù)沒(méi)有主被叫之分，因此只需要判斷PS業(yè)務(wù)起呼次數(shù)。由于測(cè)試中可能下載完成導(dǎo)致轉(zhuǎn)Idle，再回來(lái)時(shí)候是不需要重新?lián)芴?hào)，因此只需要統(tǒng)計(jì)PDP激活的次數(shù)。PS業(yè)務(wù)撥號(hào)相關(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），可以得到初步的撥號(hào)次數(shù)：

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

Unkown = 1

#

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

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

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

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

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

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

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

2.3.2 被叫引起呼損分析

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

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

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

2.3.3 呼損案例分析

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

在生成的report.txt中的統(tǒng)計(jì)MO fail的次數(shù)可以認(rèn)為是在這個(gè)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

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

根據(jù)時(shí)間點(diǎn)再到信令中去分析是哪里出了問(wèn)題，從這條消息中我們可以看到disconnect的原因?yàn)閡ser busy，從而可以認(rèn)為此次呼損是因?yàn)楸唤杏脩粢驗(yàn)榉泵Χ尫糯舜芜B接。

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

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

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

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

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

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

2.5 注意事項(xiàng)

2.5.1 IMSIDetachIndication異常

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

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

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

2.5.3 2-3G互操作

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