會計學1W高級尋呼過程分析培訓前言

尋呼是接入過程中一個主要的行為，也是優化接入過程性能的一個主要方面。本文檔概要介紹了尋呼的基本過程，在此基礎上對尋呼相關的關鍵參數、信令、性能等內容進行了分析，幫助使用者熟悉WCDMA的尋呼過程。第1頁/共57頁課程目標尋呼的主要過程尋呼過程的消息尋呼性能分析學習完本課程，您將能夠熟悉：第2頁/共57頁課程內容 T第一章尋呼的主要過程第二章尋呼過程的消息第三章尋呼過程的性能第3頁/共57頁第一章尋呼的主要過程第一節尋呼的類型第二節尋呼流程第三節DRX過程第4頁/共57頁尋呼的類型PagingType1：應用于UE處于idle、CELL_PCH、URA_PCH狀態時。PagingType2:應用于UE處于CELL_FACH或者CELL_DCH狀態時。第5頁/共57頁尋呼的類型CN發起的尋呼：CN發起尋呼的目的是使CN能夠請求UTRAN聯系UE。尋呼過程在IU接口使用無連接的信令過程。CN通過發送尋呼消息觸發尋呼過程，UTRAN則將CN尋呼消息通過UU接口上的尋呼過程發送給UE，使得被尋呼的UE發起與CN的信令連接建立過程。UTRAN發起的尋呼：當系統消息發生改變時，UTRAN為了通知處在空閑模式、CELL_PCH和URA_PCH狀態下的UE進行系統消息更新，會觸發尋呼過程。為了觸發處于CELL_PCH，URA_PCH狀態下的UE進行狀態遷移，UTRAN會進行一次尋呼流程，作為對該尋呼的一種應答形式，UE會相應的發起一次小區更新或URA更新過程。

第6頁/共57頁第一章尋呼的主要過程第一節尋呼的類型第二節尋呼流程第三節DRX過程第7頁/共57頁尋呼流程尋呼類型1CN發起的尋呼：如果IU接口的PAGING消息中帶有LAI或者RAI，RNC會向指定位置區或路由區的所有小區下發PAGINGTYPE1消息；如果沒有LAI或者RAI，RNC會向本RNC的所有小區下發PAGINGTYPE1消息。如下圖所示，CN在一個位置區LA中發起尋呼，LA分布在兩個RNC中。RNC收到尋呼消息后，根據LAI查找與其對應的所有小區，然后計算出尋呼時刻，尋呼時刻到來時在PCCH上向這些小區發送尋呼類型1消息。UTRAN發起的尋呼：當UE處于CELL_PCH或URA_PCH狀態時，如果UTRAN需要和UE進行信息交互，包括信令和數據，需要在PCCH上發送尋呼類型1來通知UE從CELL_PCH或URA_PCH遷移到CELL_FACH，UE通過小區更新的過程來完成狀態遷移。

第8頁/共57頁尋呼流程尋呼類型1第9頁/共57頁尋呼流程尋呼類型2如果UE處于CELL_DCH或者CELL_FACH狀態，UTRAN會在DCCH上向被尋呼的UE發送尋呼類型2消息。第10頁/共57頁尋呼流程UE收到尋呼后的行為

UTRAN在同一尋呼時刻可以對多個UE進行尋呼，每個被呼UE的信息包含在PAGINGTYPE1中的“pagingrecord”。若包含信息元素“BCCHmodificationinfo”，任何在空閑模式、CELL_PCH或URA_PCH狀態的UE應重新讀取系統消息，不去理會“Pagingrecord”的內容。其他：如果UE在空閑模式，UE將：

1、若信息元素"Usedpagingidentitypagingoriginator"為一個CN標識，則比較其中包含的CNIE“UE標識類型”和所有其分配的CNUE標識；若找到一個相匹配，則指示尋呼接收；

2、否則，UE將忽略該尋呼記錄。如果UE在連接模式，UE將：

1、若信息元素"Usedpagingidentity"為UTRAN，并且這個U-RNTI和已分配給UE的U-RNTI相同： －如果包括可選信息元素“CNoriginatedpagetoconnectedmodeUE”，則UE指示尋呼接受； －如果不包括可選信息元素“CNoriginatedpagetoconnectedmodeUE”，UE執行以“pagingresponse”為原因的小區更新過程；

2、若信息元素“Usedpagingidentity”不為UTRAN，UE忽略該尋呼記錄。第11頁/共57頁第一章尋呼的主要過程第一節尋呼的類型第二節尋呼流程第三節DRX過程第12頁/共57頁DRX過程PICH尋呼指示信道（PICH）是固定速率的物理信道（擴頻因子為256），用于攜帶尋呼指示（PI）。PICH總是和PCH所映射的SCCPCH相關聯。下圖給出了PICH的幀結構。一個長度為10ms的PICH由300bit組成，其中288bit(b0,b1,……,b288)用于攜帶尋呼指示，剩余12個bit留作后用。第13頁/共57頁DRX過程Numberofpagingindicatorsperframe(Np)Pq=1Pq=0Np=18{b16q,…,b16q+15}={1,1,…,1}{b16q,…,b16q+15}={0,0,…,0}Np=36{b8q,…,b8q+7}={1,1,…,1}{b8q,…,b8q+7}={0,0,…,0}Np=72{b4q,…,b4q+3}={1,1,…,1}{b4q,…,b4q+3}={0,0,…,0}Np=144{b2q,b2q+1}={1,1}{b2q,b2q+1}={0,0}每個PICH幀攜帶NP個尋呼指示，NP定義了PICH信道上每幀支持的最多尋呼指示數，UE在小區系統消息中獲取NP的值。NP的取值為18，36，72，144，相當于將288個bit分為NP個等份，每等份有288/NP個bits，每等份就是一個尋呼指示（PI）。MappingofpagingindicatorsPqtoPICHbits第14頁/共57頁DRX過程PICH和SCCPCH的關聯尋呼指示信道（PICH），用于攜帶尋呼指示（PI）。PCH承載于SCCPCH信道，其攜帶被尋呼的UE的具體信息。PICH總是和PCH所映射的SCCPCH相關聯。PICH無線幀的尾部比隨路的SCCPCH提前7680chips。PICH和SCCPCH的定時關系如下圖所示：第15頁/共57頁DRX過程UE采用非連續的方式偵聽PICH，監視尋呼指示PI，如下圖所示UE要監視每個尋呼周期中紅點所指示的幀（pagingoccasions），然后解碼該幀第q個PI，q的計算如下。第16頁/共57頁DRX過程DRX循環長度和尋呼時刻UE在空閑模式下按一定的周期去解碼PICH，只有存在尋呼指示時，才會去解碼隨路的SCCPCH信息，即不連續接收方式（DRX）。空閑模式下DRX尋呼周期的計算公式：

DRXcyclelength＝(2^K)*PBPframes其中：K為IE“CNdomainspecificDRXcyclelengthcoefficient”，目前CS和PS的K值都是6；PBP為尋呼塊周期（主要用于TDD模式），FDD模式下，PBP=1。UE尋呼時刻的計算公式：

PagingOccasion（CELLSFN）={(IMSIdivM)mod(DRXcyclelengthdivPBP)}*PBP+n*DRXcyclelength+FrameOffset這里n=0,1,2……，只要計算出的PagingOccasion小于SFN的最大值4096，在FDD情況下FrameOffset=0，M是承載PCH的SCCPCH的個數，通常為1。上述公式可以簡化為：

SFN=IMSImod(2^K)+n*(2^K)

第17頁/共57頁DRX過程UE通過計算出自己的尋呼指示下標P（PICH每幀的第q等份bits）：其中PI=DRXindexmodNP=(IMSIdiv8192)modNP，SFN就是UE的尋呼時刻，為PICH開始出現時PCCPCH的SFN。根據以上公式，UE可知道自己PI的下標，這樣UE可以僅監視PICH中的與自己關聯的bits，一旦發現它們被置為“1”時，UE就知道自己被尋呼了。第18頁/共57頁DRX過程尋呼信道選擇系統信息塊類型5（SIB5）規定了空閑模式使用的尋呼信道。在一個小區內，可建立一個或幾個PCH，在系統信息中指出的每個SCCPCH可承載一個PCH，因此，對于每個規定的PCH都指出一個唯一對應的PICH。如果在SIB5中規定了不只一個PCH和相關的PICH，UE將根據如下規則進行選擇：UE將基于IMSI從SIB5列出的SCCPCH中選擇一個如下：

IndexofselectedSCCPCH=IMSImodK

這里，K等于列出承載一個PCH的SCCPCH的個數，只承載一個FACH的SCCPCH將不計數。一般情況下，K值取1。目前一般實現的是一個小區配置一個PICH和一個SCCPCH，SCCPCH上承載兩個FACH和一個PCH。

第19頁/共57頁DRX過程DRX應用舉例小區建立后，廣播的系統信息中，有關尋呼的參數設置為：IE“CNdomainspecificDRXcyclelengthcoefficient”：6IE“NumberofPIperframe”：36UE接收到這些信息后，計算出自己的尋呼時間、PI以及p值。現有一個用戶，其IMSI為“448835805669362”，則該UE的計算結果如下：DRXcyclelength=64（2的6次方）CellSFN＝“448835805669362”mod64+n*64=50+64*n(n=0,1,2,...)（假設此處n取值為3）PI=(448835805669362div8192)mod36=14q=(14+[((18*(242+[242/8]+[242/64]+[242/512]))mod144)*0.25])mod36=27從上面的計算可知，該小區PICH每幀攜帶36個尋呼指示，每個尋呼指示有288/36=8個bit組成，UE需要監視每個PICH無線幀的bit216（27×8）～bit223，如果這些8個bit變成了"1"，UE知道自己可能被尋呼了，要在SCCPCH上接收尋呼消息。第20頁/共57頁課程內容 T第一章尋呼的主要過程第二章尋呼過程的消息第三章尋呼過程的性能第21頁/共57頁第二章尋呼過程的消息第一節L3信令分析第二節L2信令分析第22頁/共57頁L3信令分析與尋呼相關的信令主要包括：Iu：PagingIub：“COMMONTRANSPORTCHANNELSETUPREQUEST”（配置PCH、PICH參數）Uu：尋呼類型1、尋呼類型2、系統消息1、系統消息5。第23頁/共57頁IU口尋呼PagingCN如果需要和UE建立信令連接，就會在IU口發起尋呼過程。CN下發的PAGING消息包含以下信元：CNDomainIndicator：必選信元，表示尋呼消息來自CS還是PS域。PermanentNASUEIdentity：必選信元，被尋呼UE的IMSI。DRXCycleLengthCoefficient：可選信元，DRX循環長度系數K，用于計算UE的DRX周期，如果該信元存在UTRAN就透傳給UE。UE可能會收到CS、PS、UTRAN配置的K值，UE取三者的最小值。TemporaryUEIdentity：可選信元，CN給UE分配的臨時標識（TMSI或PTMSI），如果此信元不存在，UTRAN就使用IMSI進行尋呼。PagingArea：CS尋呼使用位置區標識LAI（MCC+MNC+LAC），PS的尋呼使用路由區標識RAI（LAI+RAC）。PagingCause：發送尋呼消息的原因，詳細的尋呼原因可以參考3GPPTS25.413協議（主要是terminatingcall/signalling等）。NonSearchingIndicator：可選信元，CN指示RNC是否進行協作尋呼。如果該信元不存在或者信元的值為“Searching”，并且UTRAN檢測到UE處于連接態，UTRAN會在空口發起尋呼類型2，其它情況下發起尋呼類型1。第24頁/共57頁IU口尋呼IU口尋呼信令解析

第25頁/共57頁尋呼類型1尋呼類型1UTRAN可以通過尋呼分組在一個尋呼類型1消息中對多個UE進行尋呼，尋呼類型1的信令解析如下圖所示。尋呼類型1包含以下信元：Pagingrecordlist：協議規定每個尋呼時刻最多可以尋呼8個UE，對應8個UE尋呼記錄，每個尋呼記錄中包含尋呼的來源。如果是CN發起的尋呼，要給出CN的域標識、UE的NAS層標識、尋呼原因等信息；如果是UTRAN發起的尋呼，要給出AS層UE標識URNTI。BCCHmodificationinfo：可選信元，使用valuetag標識系統信息的改變。如果該信元存在，UE會忽略Pagingrecordlist，去讀系統消息。第26頁/共57頁尋呼類型1尋呼類型1第27頁/共57頁尋呼類型2尋呼類型2對處于CELL_DCH或CELL_FACH狀態的UE，UTRAN通過在DCCH上發送PAGINGTYPE2消息啟動該過程。UTRAN可以在進行其他過程時發送PAGINGTYPE2消息，同時那個過程的狀態不應受到影響，除非另有說明。UTRAN應將信息元素“Pagingcause”設為從上層接收的尋呼原因。如果沒有得到，UTRAN將其設為“Terminatingcauseunknown”。第28頁/共57頁公共傳輸信道建立請求COMMONTRANSPORTCHANNELSETUPREQUEST

（IUB）RNC通過IUB口信令“公共傳輸信道建立請求”來通知NODEBPCH傳輸信道參數和PICH的相關參數。從下圖可以看出，PCH的兩種傳輸塊格式（0x240，1x240），功率相對PCPICH大2個dB；PICH的NP值為36，功率比PCPICH小3個dB。第29頁/共57頁公共傳輸信道建立請求公共傳輸信道建立請求（IUB）第30頁/共57頁系統消息1系統消息1UTRAN通過系統消息1通知UEDRX循環周期系數，如下圖所示，CS、PS的DRX循環周期系數都是8。第31頁/共57頁系統消息5系統消息5UE通過讀系統消息5得到PCH的傳輸格式和PICH的NP值。

第32頁/共57頁第二章尋呼過程的消息第一節L3信令分析第二節L2信令分析第33頁/共57頁L2信令分析L2信令分析第34頁/共57頁L2信令分析L2信令分析從上圖可以看出PCCH、MACC、PCHFP、SCCPCH間的映射關系，PCCH在RLC層采用TM模式，由MACC進行尋呼分組的調度。PCH的相關特性在PCHFP幀中得到體現，PCH數據幀包括尋呼指示信息和尋呼消息。為了尋呼一個UE，兩個連續PCH數據幀用連續CFN發送，第一幀包含尋呼指示信息，第二幀包括尋呼消息。對于NODEB來說，除了NP通過公共傳輸信道建立獲得，其它參數都體現在高層下發的PCHFP幀中，PI包含在PIbitmap中，DRXCyclelength是由具有相同的PI指示的PCHFP的時間間隔決定，尋呼時刻可以由PCHFP中的CFN計算得到。PCHFP幀結構如下圖所示。第35頁/共57頁L2信令分析PCHFP結構第36頁/共57頁L2信令分析其中數據幀中的各單元描述如下：頭部CRC：循環容余多項式是按一個數據幀的頭用多項式（X^7+X^6+X^2+1）來計算的。CRC的計算應包括頭中的所有比特。值范圍：{0-127}，字段長度：7個比特。幀類型：描述它是一個控制幀還是數據幀。值范圍：{0=數據,1=控制}，字段長度：1個比特。連接幀號(CFN)：指示在上行鏈路上接收或將要在下行鏈路上發送的第一個數據是哪一個無線幀。值范圍和字段長度取決于CFN所用的傳送信道。值范圍(PCH)：{0-4095}，字段長度(PCH)：12個比特；其它傳輸信道的CFN范圍（0-255）。傳輸格式指示：TFI是用于傳送一個TTI的傳送格式的標識號。值范圍：{0-31}，字段長度：5個比特。第37頁/共57頁L2信令分析傳輸塊：傳輸塊為一個要傳送的或通過無線接口已接收的數據塊。TFI指示的傳輸格式描述了傳輸塊長度和傳輸塊集合大小。凈荷CRC：循環容余多項式是按一個數據幀的凈荷用多項式（X^16+X^15+X^2+1）來計算的。CRC的計算應包括數據幀的凈荷中的所有比特，字段長度：16個比特。尋呼指示(PI)：描述凈荷中是否出現PIBitmap。值范圍：{0=凈荷中無PI-Bitmap,1=凈荷中有PI-bitmap}，字段長度：1個比特。尋呼指示比特映射(PI-bitmap)：尋呼指示PI0..PIN-1的bitmap。第一個字節的Bit7包含PI0，第一個字節的Bit6包含PI1,,...,第二個字節的Bit7包含PI8，并一直這樣下去。值范圍：{18,36,72或144尋呼指示}。字段長度：3,5,9或18字節。如果PI-bitmap為1，標識監聽該尋呼指示位的手機被尋呼。第38頁/共57頁課程內容 T第一章尋呼的主要過程第二章尋呼過程的消息第三章尋呼過程的性能第39頁/共57頁第三章尋呼過程的性能第一節尋呼調度第二節尋呼參數分析第三節尋呼話統與告警第四節尋呼異常情況第40頁/共57頁尋呼調度尋呼調度在MACC進行，主要動作：RNC的L3接到CN來的尋呼消息后，判斷如果系統沒有過載就將尋呼消息發給MACC，如果系統處于過載狀態就丟棄尋呼消息。MACC收到上層發來的尋呼消息后，計算出尋呼時刻，在離當前CFN最近的一個尋呼周期的對應位置將尋呼記錄保存下來，對于每個尋呼時刻MACC最多保存8個尋呼記錄，如果超過8個就會丟棄。在每個尋呼時刻到來時，MACC對該尋呼時刻對應的尋呼記錄進行編碼后下發給NODEB，然后清除尋呼記錄，NODEB在小區尋呼信道下發。如果系統消息更新引起的尋呼，MACC立即編碼下發，并清除所有的尋呼記錄。第41頁/共57頁尋呼調度PCH容量：目前MACC支持的PCH的傳輸塊為240bit，每幀支持的編碼后的尋呼消息不能超過240bit。根據尋呼類型1的信元結構和ASN.1PER編碼規則，如果尋呼消息的UE標識時IMSI，每個尋呼時刻最多支持3個UE，如果UE標識是TMSI或者PTMSI最多支持5個UE。硬件處理能力問題：以目前PCH的編碼方式，一個尋呼幀尋呼的UE的個數還不能達到協議值8，如果在同一尋呼時刻尋呼UE的個數超過系統的處理能力，就會造成尋呼丟失，造成呼損的情況。根據尋呼時刻的計算方式，在配置IMSI時要進行詳細規劃，保證每個UE的尋呼時刻均勻分布在一個尋呼周期內每個幀上。網絡可以采取重發尋呼來提高UE的尋呼成功率。CN在尋呼定時器超時后在IU口重發尋呼消息，UTRAN也可以在MACC調度時重發，表現在不同的尋呼周期內重發。第42頁/共57頁第三章尋呼過程的性能第一節尋呼調度第二節尋呼參數分析第三節尋呼話統與告警第四節尋呼異常情況第43頁/共57頁尋呼參數分析DRX尋呼周期系數DRX尋呼周期系數K值決定了DRX周期長度，K值越大，DRX周期就越長，UE功耗會降低，但是UE尋呼周期變長；如果K值過小，尋呼周期變小，UE處理尋呼開銷和功耗都會增加。協議值給出范圍2~12，目前我司取值6，尋呼周期為0.64秒。UE的DRX尋呼周期系數有三個來源：系統消息、CN的尋呼消息、UTRAN的Uu口信令，并且CS、PS的處理方式也不一樣。對于PS域，DRX尋呼周期系數由UE和SGSN通過NAS層消息（attach過程）協商，不管UE處于IDLE或者是連接狀態都以協商數據為準，如果協商失敗則使用CS域的尋呼系數。對于CS域，如果UE在IDLE狀態下，DRX尋呼周期系數使用系統消息、CN的尋呼消息中的最小值；如果UE在連接狀態，DRX尋呼周期系數使用系統消息、CN的尋呼消息、UTRAN的UU口信令中的最小值。第44頁/共57頁尋呼參數分析DRX尋呼周期系數（二）

RNC有兩條MML命令可以修改DRX尋呼周期系數：1、SETFRC修改UTRAN的DRX尋呼周期系數(“DRXCYCLELENCOEF”)，通過如下信令通知UE：UU_CELL_UPDATE_CONFIRM、UU_URA_UPDATE_CONFIRM、UU_PH_CH_RECFG、UU_TR_CH_RECFG、UU_RB_SETUP、UU_RB_REL、UU_RB_RECFG2、MODCNDOMAIN修改CS、PS的DRX尋呼周期系數，修改后會發尋呼類型1通知UE讀更新后的系統消息（inIdleMode）。

第45頁/共57頁尋呼參數分析NP值Np是物理信道PICH在一幀中下發的PI尋呼指示數，取值范圍在（18，36，72，144），該參數在系統消息5中通過“NumberofPIperframe”指示。UE會在確定的尋呼時機接收PICH發送的PI幀，只有相應的PI指示有效，UE才會去解調后續的S-CCPCH幀。Np參數將所有的UE分成了Np組，每一個組中所有的UE使用同一個PI。Np的取值對網絡的影響：Np的值設置過小，則每組中對應的UE數目較多，對每個UE而言，PI指示出現的概率增大，被喚醒的次數越多；Np值設置過大，則每組中對應的UE數目較少，對每個IMSI而言，PI指示出現的概率也較小，被喚醒的次數也較少；Np越大，對UE的PICH解調性能要求越高。該參數通過ADDPICH命令設置（“PICHMODE”）。

第46頁/共57頁尋呼參數分析尋呼重發次數和時間間隔為了提高尋呼的成功率，CN和RNC都會重發尋呼消息。但是尋呼重發會造成尋呼量的增加，特別是在空中接口公共下行信道擁塞的情況下，大大浪費下行信道資源，造成新的尋呼消息不能及時下發。為了兼顧尋呼成功率和尋呼效率，CN尋呼重發次數和時間間隔要和UTRAN的重發結合起來考慮。目前我司的實現是RNC重發一次尋呼類型1消息，前后兩次的間隔是一個尋呼周期，DRX循環周期系數取值6，也就是間隔640ms。CN最多支持4次尋呼重發，即CN支持尋呼消息的5次發送。CN尋呼重發時間間隔可以設由CN通過軟參設置。設置CN尋呼重發次數和時間間隔的命令為MODPGCTRL；設置RNC尋呼重發次數的命令為SETWFMRCFGDATA（“MACCPAGEREPEAT”）。第47頁/共57頁尋呼參數分析尋呼重發次數和時間間隔（二）在CN重發1次的情況下，CN尋呼重發的時間間隔可以按以下考慮：如果UTRAN不重發，CN重發時間間隔應該大于一個DRX周期（640ms），可以取1s。從以上的尋呼調度可以看出，當一個尋呼消息從CN發到UTRAN，UTRAN計算出的尋呼時刻CFN離當前PCHCFN的最大時間間隔是一個DRX周期（640ms），如果在這個時間間隔內CN再發一個尋呼消息過來，上一個尋呼消息還沒有發出，這樣會造成不必要的信道帶寬浪費。如果UTRAN重發1次，CN重發時間應該大于2個DRX周期。遵循一個原則，CN應該等到UTRAN完成上一條尋呼消息的發送和重發后再重發下一條尋呼消息。為了保證這個原則，可以同時調整CN的重發次數、重發時間間隔、UTRAN重發次數、DRX尋呼周期等參數使其滿足這個關系原則。

第48頁/共57頁第三章尋呼過程的性能第一節尋呼調度第二節尋呼參數分析第三節尋呼話統與告警第四節尋呼異常情況第49頁/共57頁尋呼話統與告警尋呼話統RNC的尋呼話統指標如下表所示。其中“CN_PAGE_IDLE_UE_SUCC_RATE”和“UTRAN_PAGE1_SUCC_RATE”兩個主要指標表征了尋呼的性能。在CN側也可以統計尋呼的成功率、第一次/第二次尋呼的成功率等。話統指標名稱話統指標含義話統指標標準測量點CN_PAGE_REQ統計IU接口尋呼的次數收到CN發起的PAGING消息CN_PAGE_IDLE_UE_REQ統計IU接口尋呼空閑用戶的次數收到CN發起的PAGING消息，且被尋呼的UE當前為空閑態CN_PAGE_IDLE_UE_SUCC統計尋呼空閑用戶成功的次數收到UE的RRC連接請求消息，且請求原因為被叫類原因，如“TerminatingConversationalCall”UTRAN