WCDMA基本信令流程匯總課件

1駱安邁淺談WCDMA基本信令流程1駱安邁淺談WCDMA基本信令流程2一、UTRAN基本信令流程

UTRAN協(xié)議結(jié)構(gòu)UTRAN信令基本無線信令流程二、獲取信令流程DT的LOG文件登錄RNC采集信令正常信令流程模板三、DT信令流程分析案例嵊州天池制藥被叫掉話嵊州奧力的主被叫掉話內(nèi)容2一、UTRAN基本信令流程內(nèi)容3一、UTRAN基本信令流程

3一、UTRAN基本信令流程4UMTS通用接口

4UMTS通用接口5UTRAN結(jié)構(gòu)圖5UTRAN結(jié)構(gòu)圖6Uu接口●3層：L1：物理層；L2：鏈路層（MAC、RLC、PDCP、BMC）；L3：網(wǎng)絡(luò)層（RRC），只有控制面，沒有用戶面?！?面：控制面，用戶面。6Uu接口●3層：L1：物理層；L2：鏈路層（MAC、RLC7UTRAN地面接口●從水平看，協(xié)議結(jié)構(gòu)主要由兩個(gè)層組成：無線網(wǎng)絡(luò)層（RadioNetworkLayer）、傳輸網(wǎng)絡(luò)層（TransportNetworkLayer）。所有和UTRAN有關(guān)的事件（比如信令和業(yè)務(wù)）都只體現(xiàn)在無線網(wǎng)絡(luò)層。而傳輸網(wǎng)絡(luò)層中的協(xié)議棧只是被UTRAN選擇用來做承載的。傳輸網(wǎng)絡(luò)層中的協(xié)議不是由3GPP制定的?！駨拇怪笨?，協(xié)議結(jié)構(gòu)主要由三個(gè)面組成：控制面（ControlPlane）、用戶面（UserPlane）和傳輸網(wǎng)絡(luò)控制面（TransportNetworkControlPlane）。7UTRAN地面接口●從水平看，協(xié)議結(jié)構(gòu)主要由兩個(gè)層組成：無8Iu_CS接口協(xié)議結(jié)構(gòu)8Iu_CS接口協(xié)議結(jié)構(gòu)9Iu_PS接口協(xié)議結(jié)構(gòu)9Iu_PS接口協(xié)議結(jié)構(gòu)10Iub接口協(xié)議結(jié)構(gòu)10Iub接口協(xié)議結(jié)構(gòu)11Iur接口協(xié)議結(jié)構(gòu)11Iur接口協(xié)議結(jié)構(gòu)12RNC無線網(wǎng)絡(luò)控制面處理協(xié)議12RNC無線網(wǎng)絡(luò)控制面處理協(xié)議13所關(guān)心的接口信令協(xié)議●空中接口：Uu。（與UTRAN的接口）L3：RRC（RNC）L2：RLC、MAC（RNC）L1：物理層（NodeB）●地面接口：無線網(wǎng)絡(luò)層：Iu：RANAPIub：NBAPIur：RNSAP傳輸網(wǎng)絡(luò)層。（略）13所關(guān)心的接口信令協(xié)議●空中接口：Uu。（與UTRAN的接14CS域協(xié)議棧14CS域協(xié)議棧15PS域協(xié)議棧15PS域協(xié)議棧16語音數(shù)據(jù)塊流程圖（下行）16語音數(shù)據(jù)塊流程圖（下行）17CN發(fā)起的尋呼消息流程圖

17CN發(fā)起的尋呼消息流程圖18信令流程分類在協(xié)議棧中，RRC和RANAP層及其以下的協(xié)議層稱為接入層，它們之上為非接入層。簡單地說，接入層的流程，也就是指無線接入層的設(shè)備RNC、NodeB需要參與處理的流程。非接入層的流程，就是指只有UE和CN需要處理的信令流程，無線接入網(wǎng)絡(luò)RNC、NodeB只是透傳，是不需要處理的。通過接入層的信令交互，在UE和CN之間建立起了信令通路，從而就能進(jìn)行非接入層信令流程了。18信令流程分類在協(xié)議棧中，RRC和RANAP層及其以下的協(xié)19信令流程分類●接入層的信令流程：PLMN選擇小區(qū)選擇無線資源管理流程：RRC連接建立流程UE和CN之間的信令建立流程RAB建立流程呼叫釋放流程切換流程SRNS重定位流程●非接入層的信令流程：電路域的移動(dòng)性管理電路域的呼叫控制分組域的移動(dòng)性管理分組域的會(huì)話管理19信令流程分類●接入層的信令流程：20基本信令流程總述

用戶從開機(jī)、進(jìn)行業(yè)務(wù)到關(guān)機(jī)的整個(gè)業(yè)務(wù)流程（只關(guān)注接入層的流程）20基本信令流程總述用戶從開機(jī)、進(jìn)行業(yè)務(wù)到關(guān)機(jī)的整個(gè)業(yè)務(wù)流21尋呼流程

●尋呼空閑模式或PCH狀態(tài)下的UE作用：（UTRAN通過在PCCH上發(fā)送一條PAGINGTYPE1消息來啟動(dòng)尋呼過程）為了建立一次呼叫或一條信令連接，網(wǎng)絡(luò)側(cè)的高層發(fā)起尋呼過程；為了將UE的狀態(tài)從CELL_PCH或URA_PCH狀態(tài)遷移到CELL_FACH狀態(tài)，UTRAN發(fā)起尋呼以觸發(fā)UE狀態(tài)的遷移；當(dāng)系統(tǒng)消息發(fā)生改變時(shí)，UTRAN發(fā)起空閑模式、CELL_PCH和URA_PCH狀態(tài)下的尋呼，以觸發(fā)UE讀取更新后的系統(tǒng)信息。21尋呼流程●尋呼空閑模式或PCH狀態(tài)下的UE22尋呼流程

●尋呼CELL_DCH或CELL_FACH狀態(tài)下的UE

對于處于連接模式CELL_DCH或CELL_FACH狀態(tài)的UE，UTRAN通過在DCCH（專用控制信道）上發(fā)送一條PAGINGTYPE2消息來發(fā)起尋呼過程。這種尋呼也叫做專用尋呼過程。為了建立一次呼叫或一條信令連接，網(wǎng)絡(luò)側(cè)的高層發(fā)起尋呼過程。22尋呼流程●尋呼CELL_DCH或CELL_FACH狀態(tài)23尋呼與模式、狀態(tài)的關(guān)系

注**：如果在UE建立CS呼叫的這個(gè)時(shí)間點(diǎn)上，有一個(gè)來自PS域的尋呼請求。注***：手機(jī)正在上網(wǎng)，收到一個(gè)被叫電話。尋呼類型1：通過PCCH發(fā)送；尋呼類型2：通過DCCH發(fā)送。系統(tǒng)信息改變指示消息：UTRAN通過BCCH（在FACH信道上）發(fā)送“系統(tǒng)信息更新改變指示”消息SYSTEMINFORMATIONCHANGEINDICATION，發(fā)送MIB新的值標(biāo)簽。通知在CELL_FACH（CELL_DCH僅TDD）狀態(tài)下的UE。參見SGPP.TS.25.331-10.2.49R6。23尋呼與模式、狀態(tài)的關(guān)系注**：如果在UE建立CS呼叫的24RRC連接建立流程

●RRC連接建立在專用信道上●RRC連接建立在公共信道上當(dāng)RRC連接建立在公共信道上時(shí)，因?yàn)橛玫氖且呀?jīng)建立好的小區(qū)公共資源，所以這里無需建立無線鏈路和用戶面的數(shù)據(jù)傳輸承載，即上圖去掉3、4、5步。目前都使用RRC連接建立在專用信道上。24RRC連接建立流程●RRC連接建立在專用信道上●RRC25NAS信令建立流程

直傳消息指UE與CN之間的信令交互NAS信息，如鑒權(quán)、業(yè)務(wù)請求、連接建立等，由于這些消息在RNC透明傳輸，所以叫直傳消息。RNC在收到第一條直傳消息，即初始直傳消息INITIALDIRECTTRANSFER時(shí)，將建立與CN之間的信令連接，該連接建立于SCCP之上。初始直傳：25NAS信令建立流程直傳消息指UE與CN之間的信令交互N26NAS信令建立流程

信令連接建立成功后，UE發(fā)送到CN的消息，通過上行直傳消息UPLINKDIRECTTRANSFER發(fā)送到RNC，RNC將其轉(zhuǎn)換為直傳消息DIRECTTRANSFER（SETUP）發(fā)送到CN；CN發(fā)送到UE的消息，通過直傳消息DIRECTTRANSFER發(fā)送到RNC，RNC將其轉(zhuǎn)換為下行直傳消息DOWNLINKDIRECTTRANSFER發(fā)送到UE。上行直傳：下行直傳：26NAS信令建立流程信令連接建立成功后，UE發(fā)送到CN的27RAB建立流程

RAB是指用戶平面的承載，用于UE和CN之間傳送語音、數(shù)據(jù)及多媒體業(yè)務(wù)。UE首先要完成RRC連接建立，然后才能建立RAB。（目前用同步重配置RL）27RAB建立流程RAB是指用戶平面的承載，用于UE和CN28呼叫釋放流程

最終的資源釋放過程都是由CN發(fā)起的。正常的業(yè)務(wù)釋放有3個(gè)內(nèi)容：IU釋放RAB釋放（如果CS域只建立一種業(yè)務(wù)，采用聯(lián)合釋放。RNC收到IU釋放后，同時(shí)釋放IU和RAB）RRC釋放對于一個(gè)UE，可能存在這樣的情況：一條RRC連接對應(yīng)多個(gè)RAB，CS域和PS域各自對應(yīng)一條Iu信令連接?！癞?dāng)CS域進(jìn)行業(yè)務(wù)釋放時(shí)：如果CS域只建立了一個(gè)RAB，那么CN發(fā)起IURELEASECOMMAND消息，RNC接收到此消息后，將自動(dòng)釋放Iu信令連接和RAB。如果CS域建立了多個(gè)RAB，那么CN將只對需要釋放的RAB發(fā)起RAB釋放流程，不進(jìn)行Iu信令連接的釋放。業(yè)務(wù)釋放完成后，SRNC將判斷該RRC連接是否還有對應(yīng)的Iu信令連接（PS域），若無，則發(fā)起RRC連接釋放過程?！馪S域類似CS域。28呼叫釋放流程最終的資源釋放過程都是由CN發(fā)起的。29掉話定義

●RNC記錄的信令上看：如果在Iu接口上看到了RNC發(fā)向CN的消息為IuReleaseRequest或者RNC發(fā)給CN的消息為RABReleaseRequest消息，此時(shí)定義為異常掉話。●空中接口掉話定義：在通話過程中，如果空中接口信息滿足下面三個(gè)條件中的任何一條，可以判斷為掉話：（手機(jī)收到如下內(nèi)容）收到任何的BCH消息（即系統(tǒng)消息）。收到RRCRelease消息（原因?yàn)榉钦ａ尫臢otnormal）。收到CCDisconnect，CCReleaseComplete，CCRelease三條消息中的任何一條，而且釋放的原因?yàn)镹otNormalClearing或者NotNormal，Unspecified。29掉話定義●RNC記錄的信令上看：30切換流程

WCDMA支持的切換包括軟切換、硬切換、前向切換和系統(tǒng)間切換。軟切換和硬切換主要是由網(wǎng)絡(luò)側(cè)發(fā)起，前向切換主要是UE發(fā)起，而系統(tǒng)間切換既有網(wǎng)絡(luò)側(cè)發(fā)起的情況，又有UE發(fā)起的情況。以下流程圖都沒有包括測量報(bào)告的內(nèi)容。30切換流程WCDMA支持的切換包括軟切換、硬切換、前向切31軟切換

無線鏈路增加（1A事件）31軟切換無線鏈路增加（1A事件）32硬切換

為了UE能進(jìn)行異頻測量，在WCDMA中引入了壓縮模式技術(shù)。目前絕大多數(shù)情況下用物理信道重配置過程完成硬切換（圖中沒有包含啟動(dòng)壓縮模式的流程）。32硬切換為了UE能進(jìn)行異頻測量，在WCDMA中引入了壓縮33WCDMA→GSM系統(tǒng)間切換

圖中沒有包含啟動(dòng)壓縮模式的流程33WCDMA→GSM系統(tǒng)間切換圖中沒有包含啟動(dòng)壓縮模式的34前向切換

前向切換分為小區(qū)更新和URA更新，主要用于當(dāng)UE位置發(fā)生改變時(shí)及時(shí)更新UTRAN側(cè)關(guān)于UE的位置信息。（屬于UTRAN行為）小區(qū)更新的原因：注*：響應(yīng)尋呼指在CELL_PCH/URA_PCH狀態(tài)下收到尋呼，在CELL_FACH狀態(tài)下響應(yīng)尋呼。注**：在CELL_PCH/URA_PCH狀態(tài)下，UE的AMRLC實(shí)體發(fā)生了不可恢復(fù)的RLC錯(cuò)誤，需轉(zhuǎn)到CELL_FACH狀態(tài)。34前向切換前向切換分為小區(qū)更新和URA更新，主要用于當(dāng)U35前向切換

小區(qū)更新基本流程：發(fā)起URA更新過程的可能原因有：●URA重選；●周期性URA更新。URA更新基本流程：35前向切換小區(qū)更新基本流程：發(fā)起URA更新過程的可能原因36二、獲取信令流程36二、獲取信令流程37DT的LOG文件

可以用華為的路測軟件PROBE或后臺(tái)分析軟件ASSISTANT，一般都是用ASSISTANT進(jìn)行信令分析。實(shí)際上就是UE采集到的信令流程。查看UE中L3中RRC信令等，雙擊“L3message”。37DT的LOG文件可以用華為的路測軟件PROBE或后臺(tái)分38登錄RNC采集信令

●采信令：通過LMT（華為本地維護(hù)終端）登錄RNC。點(diǎn)擊“維護(hù)”卡片。雙擊：跟蹤管理\接口跟蹤\CDT。輸入測試手機(jī)的IMSI號碼。文檔保存在：根目錄:\HWLMT\client\output\RNC\BSC6810V200R010C01B061\trace\下面（.tmf文件）?！褡x信令：雙擊.tmf文件。38登錄RNC采集信令●采信令：39登錄RNC采集信令

39登錄RNC采集信令40正常信令流程模板

根據(jù)ASSISTANT和登錄RNC采集到的實(shí)際信令流程，整理出各種正常信令流程的模板，以便信令分析時(shí)對照。此外，列出了從哪些信令消息中可以找到的部分相關(guān)信息，例如：MCC、MNC、LAC、RAC、CPICHEc/Io、主擾碼、CI、IMSI、TMSI等。40正常信令流程模板根據(jù)ASSISTANT和登錄RNC采集41三、DT信令流程分析案例41三、DT信令流程分析案例42嵊州天池制藥被叫掉話

問題分析：經(jīng)查該被叫手機(jī)掉話時(shí)間為14:35:11.216，但掉話處的信號較好，RSCP=-79，EcIo=-10.7，應(yīng)該不會(huì)掉話。查看ASSISTANT層3信令。42嵊州天池制藥被叫掉話問題分析：43嵊州天池制藥被叫掉話

43嵊州天池制藥被叫掉話44嵊州天池制藥被叫掉話

發(fā)現(xiàn)奇怪現(xiàn)象，對應(yīng)的掉話時(shí)間處，是一個(gè)正常的RRC釋放過程，不像是掉話。再往上看，發(fā)現(xiàn)有Attach過程，說明是一個(gè)開機(jī)過程，因此不存在掉話的問題（不是通話過程）。再往上看，發(fā)現(xiàn)時(shí)間上有約2分鐘的空缺（14:33:48~14:35:10），也就是說前一段的通話與后一段的開機(jī)過程中間丟失了一部分內(nèi)容。這樣，ASSISTANT軟件由于沒有看到正常的掛機(jī)（disconnect），但發(fā)現(xiàn)了空閑狀態(tài)，所以判為掉話。懷疑是兩個(gè)LOG之間的斷點(diǎn)，經(jīng)查發(fā)現(xiàn)此空缺在LOG的中間位置，而不是在LOG的頭尾，即不是LOG之間的斷點(diǎn)，因此初步判斷為手機(jī)故障引起掉話。44嵊州天池制藥被叫掉話發(fā)現(xiàn)奇怪現(xiàn)象，對應(yīng)的掉話時(shí)間處，是45嵊州天池制藥被叫掉話

查看事件：45嵊州天池制藥被叫掉話查看事件：46嵊州天池制藥被叫掉話

從eventlist中，在掉話時(shí)間的位置沒有看到掉話事件，卻在數(shù)據(jù)斷點(diǎn)處14:33:49.499有UEDisconnected的字樣（說明手機(jī)已經(jīng)與電腦斷開），正常的被叫手機(jī)掛機(jī)情況應(yīng)該是IncomingCallDisconnected。與路測工程師溝通，此處確實(shí)出現(xiàn)手機(jī)沒電了的現(xiàn)象?？梢哉J(rèn)為手機(jī)在得電后進(jìn)行了開機(jī)過程，由于手機(jī)與電腦的連接建立需要一定的時(shí)間，故開機(jī)過程信令不能完整記錄下來。另外主叫手機(jī)工作正常，故操作者沒有停止LOG而重開LOG，由于手機(jī)斷電故障出現(xiàn)在LOG的中間位置，所以容易造成系統(tǒng)掉話的假象。46嵊州天池制藥被叫掉話從eventlist中，在掉話時(shí)47嵊州天池制藥被叫掉話

查看RNC的CDT信令跟蹤消息：由于手機(jī)突然失電，來不及通知網(wǎng)絡(luò)，使得基站收不到手機(jī)的無線信號，因此網(wǎng)絡(luò)側(cè)判斷為無線丟失而掉話。分析結(jié)論：由于手機(jī)失電，造成掉話，非網(wǎng)絡(luò)原因。47嵊州天池制藥被叫掉話查看RNC的CDT信令跟蹤消息：由48嵊州奧力的主被叫掉話

主叫：48嵊州奧力的主被叫掉話主叫：49嵊州奧力的主被叫掉話

被叫：49嵊州奧力的主被叫掉話被叫：50嵊州奧力的主被叫掉話

問題分析：該次測試為vp+dpa（手機(jī)主被叫＋數(shù)據(jù)卡）。主叫手機(jī)IMSI：460015750338003，被叫手機(jī)IMSI：460015750338131，數(shù)據(jù)卡IMSI：460015750338177。經(jīng)查掉話地點(diǎn)在同一處，掉話時(shí)間分別為主叫15:06:09.090和被叫15:06:10.363，但掉話處信號分別為主叫RSCP=83.78，EcIo=4.61；被叫RSCP=77.12，EcIo=5.46，信號較好應(yīng)該不會(huì)掉話。查看ASSISTANT層3信令：50嵊州奧力的主被叫掉話問題分析：51嵊州奧力的主被叫掉話

發(fā)現(xiàn)主被叫的掉話處均有15分鐘的數(shù)據(jù)空缺（14:51~15:06），懷疑為兩個(gè)LOG的連接處。將LOG不合并，單獨(dú)導(dǎo)入。發(fā)現(xiàn)主被叫的掉話點(diǎn)均是在兩個(gè)LOG的交接點(diǎn)，而且前1個(gè)LOG的終結(jié)點(diǎn)與后1個(gè)LOG的起始點(diǎn)也不在同一處。單獨(dú)導(dǎo)入LOG后，ASSISTANT對主被叫均沒有判斷為掉話，因此，這兩個(gè)掉話明顯是LOG合并后ASSISTANT誤判所致。按理說，停止LOG，手機(jī)應(yīng)該進(jìn)行掛機(jī)（發(fā)送disconnect）的流程，所以LOG合并后，不會(huì)誤判掉話，但這里信令為什么沒有正常釋放過程就嘎然停止？51嵊州奧力的主被叫掉話發(fā)現(xiàn)主被叫的掉話處均有15分鐘的數(shù)52嵊州奧力的主被叫掉話

查看RNC的CDT信令跟蹤消息：發(fā)現(xiàn)主被叫手機(jī)的釋放流程完整，說明在停止LOG時(shí)，手機(jī)是正常進(jìn)行釋放流程的。經(jīng)過與路測人員溝通，發(fā)現(xiàn)如果采用設(shè)置文件大小，自動(dòng)分存LOG文件的方法，則PROBE在運(yùn)行較長時(shí)間后，在分存LOG時(shí)，有時(shí)會(huì)突然吊死，這樣此后的信令數(shù)據(jù)就會(huì)丟失。此次掉話處就發(fā)生過這種情況。分析結(jié)論：由于PROBE路測軟件故障，造成路測的信令數(shù)據(jù)丟失，在LOG合并后，ASSISTANT誤判為掉話。52嵊州奧力的主被叫掉話查看RNC的CDT信令跟蹤消息：53謝謝53謝謝54駱安邁淺談WCDMA基本信令流程1駱安邁淺談WCDMA基本信令流程55一、UTRAN基本信令流程

UTRAN協(xié)議結(jié)構(gòu)UTRAN信令基本無線信令流程二、獲取信令流程DT的LOG文件登錄RNC采集信令正常信令流程模板三、DT信令流程分析案例嵊州天池制藥被叫掉話嵊州奧力的主被叫掉話內(nèi)容2一、UTRAN基本信令流程內(nèi)容56一、UTRAN基本信令流程

3一、UTRAN基本信令流程57UMTS通用接口

4UMTS通用接口58UTRAN結(jié)構(gòu)圖5UTRAN結(jié)構(gòu)圖59Uu接口●3層：L1：物理層；L2：鏈路層（MAC、RLC、PDCP、BMC）；L3：網(wǎng)絡(luò)層（RRC），只有控制面，沒有用戶面。●2面：控制面，用戶面。6Uu接口●3層：L1：物理層；L2：鏈路層（MAC、RLC60UTRAN地面接口●從水平看，協(xié)議結(jié)構(gòu)主要由兩個(gè)層組成：無線網(wǎng)絡(luò)層（RadioNetworkLayer）、傳輸網(wǎng)絡(luò)層（TransportNetworkLayer）。所有和UTRAN有關(guān)的事件（比如信令和業(yè)務(wù)）都只體現(xiàn)在無線網(wǎng)絡(luò)層。而傳輸網(wǎng)絡(luò)層中的協(xié)議棧只是被UTRAN選擇用來做承載的。傳輸網(wǎng)絡(luò)層中的協(xié)議不是由3GPP制定的?！駨拇怪笨?，協(xié)議結(jié)構(gòu)主要由三個(gè)面組成：控制面（ControlPlane）、用戶面（UserPlane）和傳輸網(wǎng)絡(luò)控制面（TransportNetworkControlPlane）。7UTRAN地面接口●從水平看，協(xié)議結(jié)構(gòu)主要由兩個(gè)層組成：無61Iu_CS接口協(xié)議結(jié)構(gòu)8Iu_CS接口協(xié)議結(jié)構(gòu)62Iu_PS接口協(xié)議結(jié)構(gòu)9Iu_PS接口協(xié)議結(jié)構(gòu)63Iub接口協(xié)議結(jié)構(gòu)10Iub接口協(xié)議結(jié)構(gòu)64Iur接口協(xié)議結(jié)構(gòu)11Iur接口協(xié)議結(jié)構(gòu)65RNC無線網(wǎng)絡(luò)控制面處理協(xié)議12RNC無線網(wǎng)絡(luò)控制面處理協(xié)議66所關(guān)心的接口信令協(xié)議●空中接口：Uu。（與UTRAN的接口）L3：RRC（RNC）L2：RLC、MAC（RNC）L1：物理層（NodeB）●地面接口：無線網(wǎng)絡(luò)層：Iu：RANAPIub：NBAPIur：RNSAP傳輸網(wǎng)絡(luò)層。（略）13所關(guān)心的接口信令協(xié)議●空中接口：Uu。（與UTRAN的接67CS域協(xié)議棧14CS域協(xié)議棧68PS域協(xié)議棧15PS域協(xié)議棧69語音數(shù)據(jù)塊流程圖（下行）16語音數(shù)據(jù)塊流程圖（下行）70CN發(fā)起的尋呼消息流程圖

17CN發(fā)起的尋呼消息流程圖71信令流程分類在協(xié)議棧中，RRC和RANAP層及其以下的協(xié)議層稱為接入層，它們之上為非接入層。簡單地說，接入層的流程，也就是指無線接入層的設(shè)備RNC、NodeB需要參與處理的流程。非接入層的流程，就是指只有UE和CN需要處理的信令流程，無線接入網(wǎng)絡(luò)RNC、NodeB只是透傳，是不需要處理的。通過接入層的信令交互，在UE和CN之間建立起了信令通路，從而就能進(jìn)行非接入層信令流程了。18信令流程分類在協(xié)議棧中，RRC和RANAP層及其以下的協(xié)72信令流程分類●接入層的信令流程：PLMN選擇小區(qū)選擇無線資源管理流程：RRC連接建立流程UE和CN之間的信令建立流程RAB建立流程呼叫釋放流程切換流程SRNS重定位流程●非接入層的信令流程：電路域的移動(dòng)性管理電路域的呼叫控制分組域的移動(dòng)性管理分組域的會(huì)話管理19信令流程分類●接入層的信令流程：73基本信令流程總述

用戶從開機(jī)、進(jìn)行業(yè)務(wù)到關(guān)機(jī)的整個(gè)業(yè)務(wù)流程（只關(guān)注接入層的流程）20基本信令流程總述用戶從開機(jī)、進(jìn)行業(yè)務(wù)到關(guān)機(jī)的整個(gè)業(yè)務(wù)流74尋呼流程

●尋呼空閑模式或PCH狀態(tài)下的UE作用：（UTRAN通過在PCCH上發(fā)送一條PAGINGTYPE1消息來啟動(dòng)尋呼過程）為了建立一次呼叫或一條信令連接，網(wǎng)絡(luò)側(cè)的高層發(fā)起尋呼過程；為了將UE的狀態(tài)從CELL_PCH或URA_PCH狀態(tài)遷移到CELL_FACH狀態(tài)，UTRAN發(fā)起尋呼以觸發(fā)UE狀態(tài)的遷移；當(dāng)系統(tǒng)消息發(fā)生改變時(shí)，UTRAN發(fā)起空閑模式、CELL_PCH和URA_PCH狀態(tài)下的尋呼，以觸發(fā)UE讀取更新后的系統(tǒng)信息。21尋呼流程●尋呼空閑模式或PCH狀態(tài)下的UE75尋呼流程

●尋呼CELL_DCH或CELL_FACH狀態(tài)下的UE

對于處于連接模式CELL_DCH或CELL_FACH狀態(tài)的UE，UTRAN通過在DCCH（專用控制信道）上發(fā)送一條PAGINGTYPE2消息來發(fā)起尋呼過程。這種尋呼也叫做專用尋呼過程。為了建立一次呼叫或一條信令連接，網(wǎng)絡(luò)側(cè)的高層發(fā)起尋呼過程。22尋呼流程●尋呼CELL_DCH或CELL_FACH狀態(tài)76尋呼與模式、狀態(tài)的關(guān)系

注**：如果在UE建立CS呼叫的這個(gè)時(shí)間點(diǎn)上，有一個(gè)來自PS域的尋呼請求。注***：手機(jī)正在上網(wǎng)，收到一個(gè)被叫電話。尋呼類型1：通過PCCH發(fā)送；尋呼類型2：通過DCCH發(fā)送。系統(tǒng)信息改變指示消息：UTRAN通過BCCH（在FACH信道上）發(fā)送“系統(tǒng)信息更新改變指示”消息SYSTEMINFORMATIONCHANGEINDICATION，發(fā)送MIB新的值標(biāo)簽。通知在CELL_FACH（CELL_DCH僅TDD）狀態(tài)下的UE。參見SGPP.TS.25.331-10.2.49R6。23尋呼與模式、狀態(tài)的關(guān)系注**：如果在UE建立CS呼叫的77RRC連接建立流程

●RRC連接建立在專用信道上●RRC連接建立在公共信道上當(dāng)RRC連接建立在公共信道上時(shí)，因?yàn)橛玫氖且呀?jīng)建立好的小區(qū)公共資源，所以這里無需建立無線鏈路和用戶面的數(shù)據(jù)傳輸承載，即上圖去掉3、4、5步。目前都使用RRC連接建立在專用信道上。24RRC連接建立流程●RRC連接建立在專用信道上●RRC78NAS信令建立流程

直傳消息指UE與CN之間的信令交互NAS信息，如鑒權(quán)、業(yè)務(wù)請求、連接建立等，由于這些消息在RNC透明傳輸，所以叫直傳消息。RNC在收到第一條直傳消息，即初始直傳消息INITIALDIRECTTRANSFER時(shí)，將建立與CN之間的信令連接，該連接建立于SCCP之上。初始直傳：25NAS信令建立流程直傳消息指UE與CN之間的信令交互N79NAS信令建立流程

信令連接建立成功后，UE發(fā)送到CN的消息，通過上行直傳消息UPLINKDIRECTTRANSFER發(fā)送到RNC，RNC將其轉(zhuǎn)換為直傳消息DIRECTTRANSFER（SETUP）發(fā)送到CN；CN發(fā)送到UE的消息，通過直傳消息DIRECTTRANSFER發(fā)送到RNC，RNC將其轉(zhuǎn)換為下行直傳消息DOWNLINKDIRECTTRANSFER發(fā)送到UE。上行直傳：下行直傳：26NAS信令建立流程信令連接建立成功后，UE發(fā)送到CN的80RAB建立流程

RAB是指用戶平面的承載，用于UE和CN之間傳送語音、數(shù)據(jù)及多媒體業(yè)務(wù)。UE首先要完成RRC連接建立，然后才能建立RAB。（目前用同步重配置RL）27RAB建立流程RAB是指用戶平面的承載，用于UE和CN81呼叫釋放流程

最終的資源釋放過程都是由CN發(fā)起的。正常的業(yè)務(wù)釋放有3個(gè)內(nèi)容：IU釋放RAB釋放（如果CS域只建立一種業(yè)務(wù)，采用聯(lián)合釋放。RNC收到IU釋放后，同時(shí)釋放IU和RAB）RRC釋放對于一個(gè)UE，可能存在這樣的情況：一條RRC連接對應(yīng)多個(gè)RAB，CS域和PS域各自對應(yīng)一條Iu信令連接?！癞?dāng)CS域進(jìn)行業(yè)務(wù)釋放時(shí)：如果CS域只建立了一個(gè)RAB，那么CN發(fā)起IURELEASECOMMAND消息，RNC接收到此消息后，將自動(dòng)釋放Iu信令連接和RAB。如果CS域建立了多個(gè)RAB，那么CN將只對需要釋放的RAB發(fā)起RAB釋放流程，不進(jìn)行Iu信令連接的釋放。業(yè)務(wù)釋放完成后，SRNC將判斷該RRC連接是否還有對應(yīng)的Iu信令連接（PS域），若無，則發(fā)起RRC連接釋放過程?！馪S域類似CS域。28呼叫釋放流程最終的資源釋放過程都是由CN發(fā)起的。82掉話定義

●RNC記錄的信令上看：如果在Iu接口上看到了RNC發(fā)向CN的消息為IuReleaseRequest或者RNC發(fā)給CN的消息為RABReleaseRequest消息，此時(shí)定義為異常掉話?！窨罩薪涌诘粼挾x：在通話過程中，如果空中接口信息滿足下面三個(gè)條件中的任何一條，可以判斷為掉話：（手機(jī)收到如下內(nèi)容）收到任何的BCH消息（即系統(tǒng)消息）。收到RRCRelease消息（原因?yàn)榉钦ａ尫臢otnormal）。收到CCDisconnect，CCReleaseComplete，CCRelease三條消息中的任何一條，而且釋放的原因?yàn)镹otNormalClearing或者NotNormal，Unspecified。29掉話定義●RNC記錄的信令上看：83切換流程

WCDMA支持的切換包括軟切換、硬切換、前向切換和系統(tǒng)間切換。軟切換和硬切換主要是由網(wǎng)絡(luò)側(cè)發(fā)起，前向切換主要是UE發(fā)起，而系統(tǒng)間切換既有網(wǎng)絡(luò)側(cè)發(fā)起的情況，又有UE發(fā)起的情況。以下流程圖都沒有包括測量報(bào)告的內(nèi)容。30切換流程WCDMA支持的切換包括軟切換、硬切換、前向切84軟切換

無線鏈路增加（1A事件）31軟切換無線鏈路增加（1A事件）85硬切換

為了UE能進(jìn)行異頻測量，在WCDMA中引入了壓縮模式技術(shù)。目前絕大多數(shù)情況下用物理信道重配置過程完成硬切換（圖中沒有包含啟動(dòng)壓縮模式的流程）。32硬切換為了UE能進(jìn)行異頻測量，在WCDMA中引入了壓縮86WCDMA→GSM系統(tǒng)間切換

圖中沒有包含啟動(dòng)壓縮模式的流程33WCDMA→GSM系統(tǒng)間切換圖中沒有包含啟動(dòng)壓縮模式的87前向切換

前向切換分為小區(qū)更新和URA更新，主要用于當(dāng)UE位置發(fā)生改變時(shí)及時(shí)更新UTRAN側(cè)關(guān)于UE的位置信息。（屬于UTRAN行為）小區(qū)更新的原因：注*：響應(yīng)尋呼指在CELL_PCH/URA_PCH狀態(tài)下收到尋呼，在CELL_FACH狀態(tài)下響應(yīng)尋呼。注**：在CELL_PCH/URA_PCH狀態(tài)下，UE的AMRLC實(shí)體發(fā)生了不可恢復(fù)的RLC錯(cuò)誤，需轉(zhuǎn)到CELL_FACH狀態(tài)。34前向切換前向切換分為小區(qū)更新和URA更新，主要用于當(dāng)U88前向切換

小區(qū)更新基本流程：發(fā)起URA更新過程的可能原因有：●URA重選；●周期性URA更新。URA更新基本流程：35前向切換小區(qū)更新基本流程：發(fā)起URA更新過程的可能原因89二、獲取信令流程36二、獲取信令流程90DT的LOG文件

可以用華為的路測軟件PROBE或后臺(tái)分析軟件ASSISTANT，一般都是用ASSISTANT進(jìn)行信令分析。實(shí)際上就是UE采集到的信令流程。查看UE中L3中RRC信令等，雙擊“L3message”。37DT的LOG文件可以用華為的路測軟件PROBE或后臺(tái)分91登錄RNC采集信令

●采信令：通過LMT（華為本地維護(hù)終端）登錄RNC。點(diǎn)擊“維護(hù)”卡片。雙擊：跟蹤管理\接口跟蹤\CDT。輸入測試手機(jī)的IMSI號碼。文檔保存在：根目錄:\HWLMT\client\output\RNC\BSC6810V200R010C01B061\trace\下面（.tmf文件）?！褡x信令：雙擊.tmf文件。38登錄RNC采集信令●采信令：92登錄RNC采集信令

39登錄RNC采集信令93正常信令流程模板

根據(jù)ASSISTANT和登錄RNC采集到的實(shí)際信令流程，整理出各種正常信令流程的模板，以便信令分析時(shí)對照。此外，列出了從哪些信令消息中可以找到的部分相關(guān)信息，例如：MCC、MNC、LAC、RAC、CPICHEc/Io、主擾碼、CI、IMSI、TMSI等。40正常信令流程模板根據(jù)ASSISTANT和登錄RNC采集94三、DT信令流程分析案例41三、DT信令流程分析案例95嵊州天池制藥被叫掉話

問題分析：經(jīng)查該被叫手機(jī)掉話時(shí)間為14:35:11.216，但掉話處的信號較好，RSCP=-79，EcIo=-10.7，應(yīng)該不會(huì)掉話。查看ASSISTANT層3信令。42嵊州天池制藥被叫掉話問題分析：96嵊州天池制藥被叫掉話

43嵊州天池制藥被叫掉話97嵊州天池制藥被叫掉話

發(fā)現(xiàn)奇怪現(xiàn)象，對應(yīng)的掉話時(shí)間處，是一個(gè)正常的RRC釋放過程，不像是掉話。再往上看，發(fā)現(xiàn)有Attach過程，說明是一個(gè)開機(jī)過程，因此不存在掉話的問題（不是通話過程）。再往上看，發(fā)現(xiàn)時(shí)間上有約2分鐘的空缺（14:33:48~14:35:10），也就是說前一段的通話與后一段的開機(jī)過程中間丟失了一部分內(nèi)容。這樣，ASSISTANT軟件由于沒有看到正常的掛機(jī)（disconnect），但發(fā)現(xiàn)了空閑狀態(tài)，所以判為掉話。懷疑是兩個(gè)LOG之間的斷點(diǎn)，經(jīng)查發(fā)現(xiàn)此空缺在LOG的中間位置，而不是在LOG的頭尾，即不是LOG之間的斷點(diǎn)，因此初步判斷為手機(jī)故障引起掉話。44嵊州天池制藥被叫掉話發(fā)現(xiàn)奇怪現(xiàn)象，對應(yīng)的掉