第一篇：深圳聯通第三方測試保障后臺信令跟蹤分析過程總結V1.0

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

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

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

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

1.2.1 信令文件處理工具包.......................................................................................4 1.2.2 生成文件內容簡介...........................................................................................5 1.3 PS業務速率統計................................................................................................................5 2 數據統計分析...........................................................................................................................7

2.1 測試號碼業務定位...................................................................................................7

2.1.1 判斷業務速率...................................................................................................7 2.1.2 判斷業務主被叫...............................................................................................8 2.2 呼叫次數統計...........................................................................................................8

2.2.1 CS業務呼叫次數統計方式..............................................................................8

2.2.1.1 主叫相關次數統計...................................................................................8 2.2.1.2 被叫相關次數統計.................................................................................10 2.2.2 PS業務撥號相關次數統計方式....................................................................11 2.3 呼損分析.................................................................................................................12 2.3.1 主叫呼損分析.................................................................................................12 2.3.2 被叫引起呼損分析.........................................................................................12 2.3.3 呼損案例分析.................................................................................................13 2.4 掉話分析.................................................................................................................14 2.4.1 CS業務掉話分析............................................................................................14 2.4.2 PS業務掉話分析............................................................................................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 后臺信令抓取任務設置和過程

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

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

再在任務詳細設置中填寫IMSI號，勾選所有選項。

1.1.2 后臺信令保存

深圳聯通信令數據保存時間分上下午保存，分別保存.std格式和.txt格式。

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

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

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

其中站點信息索引文件需要放在C盤根目錄下，即C：，使用文本編輯軟件（UEdit、Notepad等）打開來編輯。里面的數據以“cellid = 23 cellname = 金華新聯通-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，就可以在當前目錄生成名稱為之對應的多個*.txt，Report.txt的文本文件：

1.2.2 生成文件內容簡介

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

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

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

2部分：

為業務計數器列表，主要統計了該信令中各類業務主被叫成功和失敗次數，其中Unkown為部分特殊信令流程，如注冊、位置區更新等，需要在實際信令中確認。

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

4部分：為跑車路線。

1.3 PS業務速率統計

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

導入std格式碼流文件：

顯示速率相關信息：

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

在本次第三方測試中統計PS業務的速率的平均值，以及采樣次數。數據統計分析

2.1 測試號碼業務定位 2.1.1 判斷業務速率

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

可以取得該業務上下行指派速率。

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

2.1.2 判斷業務主被叫

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

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

2.2 呼叫次數統計

2.2.1 CS業務呼叫次數統計方式

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

2.2.1.1 主叫相關次數統計

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

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：獲取主叫起呼次數

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

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

Unkown = 1

#

步驟2：獲取主叫業務建立成功次數

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

步驟3：獲取主叫建立失敗次數

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

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

2.2.1.2 被叫相關次數統計

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

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：獲取被叫尋呼到次數

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

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

Unkown = 1

#

步驟2：獲取被叫業務建立成功次數

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

步驟3：獲取被叫建立失敗次數

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

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

2.2.2 PS業務撥號相關次數統計方式

測試中PS業務沒有主被叫之分，因此只需要判斷PS業務起呼次數。由于測試中可能下載完成導致轉Idle，再回來時候是不需要重新撥號，因此只需要統計PDP激活的次數。PS業務撥號相關流程如下圖：

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：獲取撥叫次數

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

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

Unkown = 1

#

步驟2：獲取撥叫成功次數

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

步驟3：獲取撥叫失敗次數

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

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

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

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

2.3.2 被叫引起呼損分析

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

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

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

2.3.3 呼損案例分析

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

在生成的report.txt中的統計MO fail的次數可以認為是在這個RNC下此次導出的數據中可能出現呼損的次數

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

Unkown = 6

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

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

2.4 掉話分析 2.4.1 CS業務掉話分析

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

2.4.2 PS業務掉話分析

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

? 如果Cause值為TRANAP_user_inactivity，則PS業務為轉空閑過程，不算掉話。

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

2.5 注意事項

2.5.1 IMSIDetachIndication異常

在測試過程中，PS業務可能會出現IMSIDetach的情況，該情況是由于數據卡或終端硬件異常導致，不能算為一種掉話。但在前面用生成的.t統計過程中會認為這是掉話。需要將這類失敗去掉。

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

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

2.5.3 2-3G互操作

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