,WCDMARNO尋呼問題分析,前言,尋呼是網(wǎng)絡(luò)聯(lián)系UE的重要途徑，和其它流程相比較，尋呼流程在無線網(wǎng)絡(luò)中表現(xiàn)出頻率高、流量大、突發(fā)性強(qiáng)等特點(diǎn)，尋呼性能關(guān)系到整個無線網(wǎng)絡(luò)的性能。所以研究尋呼問題對無線網(wǎng)絡(luò)性能具有很強(qiáng)的現(xiàn)實(shí)意義。,課程目標(biāo),尋呼問題的分析流程尋呼問題的典型案例,學(xué)習(xí)完本課程，您將能夠熟悉：,概述,如果網(wǎng)絡(luò)側(cè)需要主動聯(lián)系處于空閑模式、CELL_PCH或者URA_PCH狀態(tài)的UE，就要發(fā)起尋呼流程，尋呼是網(wǎng)絡(luò)聯(lián)系UE的重要途徑。和其它流程相比較，尋呼流程在無線網(wǎng)絡(luò)中表現(xiàn)出頻率高、流量大、突發(fā)性強(qiáng)等特點(diǎn)，尋呼性能關(guān)系到整個無線網(wǎng)絡(luò)的性能，所以研究尋呼問題對無線網(wǎng)絡(luò)性能具有很強(qiáng)的現(xiàn)實(shí)意義。從UE接收尋呼消息的角度來看，尋呼消息分為PAGINGTYPE1和PAGINGTYPE2，由UTRAN決定發(fā)送給UE的尋呼類型。PAGINGTYPE1是通過PCCH邏輯信道來尋呼處在IDLE，CELL_PCH，URA_PCH狀態(tài)的UE。PAGINGTYPE2是通過DCCH來尋呼處在CELL_FACH，CELL_DCH狀態(tài)的UE。,概述,網(wǎng)絡(luò)側(cè)會在以下情況下發(fā)起尋呼：UE被叫；小區(qū)系統(tǒng)消息更新；UE狀態(tài)遷移；一個典型的由尋呼引起的被叫流程如下圖所示。尋呼過程中可能會存在種種問題導(dǎo)致目標(biāo)UE不能正確收到尋呼消息，如在網(wǎng)絡(luò)群發(fā)短消息和全文尋呼時，不合理的尋呼策略會使得尋呼信道擁塞從而造成尋呼消息大量丟失，嚴(yán)重情形下還會造成系統(tǒng)長期過載，尋呼信道功率配比過低造成尋呼成功率低。本文將對這些導(dǎo)致尋呼異常的問題進(jìn)行深入分析，并給出其解決方法。,概述,UE被叫流程圖：,課程內(nèi)容,T,第一章尋呼問題的分析流程第二章尋呼問題的典型案例,第一章尋呼問題的分析流程,第一節(jié)分析流程第二節(jié)信息收集第三節(jié)問題定位第四節(jié)優(yōu)化驗證,分析流程,分析流程,尋呼問題分析流程如圖所示，大體分為以下幾個步驟：網(wǎng)絡(luò)信息收集：收集網(wǎng)絡(luò)與尋呼相關(guān)話統(tǒng)、告警、用戶投訴、網(wǎng)絡(luò)規(guī)劃和優(yōu)化記錄、網(wǎng)絡(luò)參數(shù)配置等信息；確定優(yōu)化目標(biāo)：確定尋呼問題優(yōu)化的KPI指標(biāo)；尋呼問題定位：定位導(dǎo)致尋呼問題的原因；尋呼問題優(yōu)化：根據(jù)定位結(jié)果采用相應(yīng)的優(yōu)化調(diào)整措施；優(yōu)化驗證：驗證優(yōu)化后的KPI指標(biāo)是否達(dá)到要求以及其它尋呼相關(guān)信息是否正常。,第一章尋呼問題的分析流程,第一節(jié)分析流程第二節(jié)信息收集第三節(jié)問題定位第四節(jié)優(yōu)化驗證,信息收集,網(wǎng)絡(luò)信息收集是尋呼問題分析的第一步，優(yōu)化人員要獲取待優(yōu)化網(wǎng)絡(luò)中與尋呼相關(guān)的話統(tǒng)、用戶投訴、告警、網(wǎng)絡(luò)規(guī)劃優(yōu)化歷史記錄、無線參數(shù)配置等等信息，為后續(xù)進(jìn)一步的深入分析做準(zhǔn)備。需要收集的信息主要包括以下幾個方面：話統(tǒng)告警用戶投訴優(yōu)化歷史記錄參數(shù)配置,信息收集,話統(tǒng)尋呼相關(guān)的話統(tǒng)指標(biāo)可以根據(jù)不同的尋呼區(qū)域分別在RNC、UMSC、SGSN話統(tǒng)臺上觀測；RNC話統(tǒng)對應(yīng)一個RNC區(qū)域，UMSC話統(tǒng)對應(yīng)一個位置區(qū)，SGSN話統(tǒng)對應(yīng)一個路由區(qū)。在實(shí)際話統(tǒng)分析過程中需要把RNC和CN的話統(tǒng)數(shù)據(jù)結(jié)合起來分析。RNC的話統(tǒng)中，需要關(guān)注“CN_PAGE_IDLE_UE_SUCC_RATE”和“UTRAN_PAGE1_SUCC_RATE”，這兩個指標(biāo)基本表征了RNC對應(yīng)尋呼區(qū)域的尋呼成功率；前者從CN的角度考察了尋呼的成功率，后者除了包含CN尋呼情況外，還包含UTRAN系統(tǒng)消息更新和UE狀態(tài)遷移兩種情況。這兩個指標(biāo)可以用來分析一個RNC區(qū)域的尋呼性能，一個RNC區(qū)域一般包括多個位置區(qū)。,信息收集,話統(tǒng)UMSC尋呼相關(guān)話統(tǒng)指標(biāo)都是基于一個位置區(qū)的。一般情況下，位置區(qū)不會跨RNC、BSC配置，可以統(tǒng)計一個位置區(qū)的尋呼成功率、第一次尋呼成功率、非第一次尋呼成功率。位置區(qū)的尋呼成功率關(guān)注一個位置區(qū)的尋呼狀況，并不關(guān)心尋呼重發(fā)次數(shù)，而第一次尋呼成功率、非第一次尋呼成功率關(guān)注尋呼重發(fā)次數(shù)對尋呼成功率的影響。SGSN尋呼相關(guān)話統(tǒng)指標(biāo)都是基于一個路由區(qū)的，可以得到某路由區(qū)的尋呼成功率。在話統(tǒng)分析過程中，要重點(diǎn)關(guān)注“位置區(qū)尋呼成功率”和“路由區(qū)尋呼成功率”，這是衡量尋呼性能的注意KPI指標(biāo)。,信息收集,告警按照目前我司的實(shí)現(xiàn)，CN和尋呼相關(guān)的告警只有“RNC過載”，當(dāng)CN接收到RNC的過載消息引發(fā)此告警。RNC為保證系統(tǒng)運(yùn)行的穩(wěn)定性，避免突發(fā)的消息風(fēng)暴對系統(tǒng)的沖擊，對包括尋呼在內(nèi)的某些處理頻率很高的消息進(jìn)行了流控。當(dāng)RNC收到CN的尋呼消息后，判斷系統(tǒng)如果處于尋呼流控狀態(tài)，就會丟棄尋呼消息，并記錄下尋呼消息丟失的個數(shù)。如果尋呼丟失比例達(dá)到一定的門限，RNC就會向CN發(fā)Overload消息，CN就會控制消息發(fā)送流量按照一定的步長減少。如果在一定的時間內(nèi)沒有收到Overload消息，IU的消息流量會逐步增長直至恢復(fù)正常。RNC目前尋呼相關(guān)的告警是“流量控制告警”，當(dāng)RNC處于尋呼流控狀態(tài)下尋呼消息會無條件丟失。當(dāng)系統(tǒng)從流控狀態(tài)恢復(fù)時，會產(chǎn)生流量“控制恢復(fù)告警”。,信息收集,用戶投訴如果尋呼消息丟失導(dǎo)致手機(jī)不能做被叫，主叫用戶會聽到系統(tǒng)提示音“用戶不在服務(wù)區(qū)”?？梢钥蛻籼幜私庥脩敉对V情況或直接聯(lián)系投訴人了解不在服務(wù)區(qū)發(fā)生情況，要重點(diǎn)關(guān)注手機(jī)被叫失敗的情況。整理投訴信息，尋找規(guī)律，觀察是否存在下屬情況：是否忙時和閑時都發(fā)生；如果尋呼失敗在話務(wù)高峰，重點(diǎn)分析尋呼擁塞的情形，如果不是在話務(wù)高峰，要分析其它因素；是否被叫手機(jī)類型相同，可能存在手機(jī)自身問題；是否投訴地點(diǎn)集中，可能是因為信號覆蓋問題；找到投訴的規(guī)律能加快問題解決的速度。,信息收集,優(yōu)化歷史記錄獲取網(wǎng)絡(luò)規(guī)劃報告，重點(diǎn)關(guān)注尋呼區(qū)域（位置區(qū)、路由區(qū)）的劃分。規(guī)劃報告應(yīng)包括網(wǎng)絡(luò)所經(jīng)歷各次擴(kuò)容的規(guī)劃報告。對于開通后網(wǎng)絡(luò)，可能在本次優(yōu)化之前已經(jīng)經(jīng)歷了優(yōu)化過程，在本次優(yōu)化開始之前應(yīng)獲得各次優(yōu)化歷史記錄，了解各次網(wǎng)絡(luò)調(diào)整過程及遺留問題。應(yīng)重點(diǎn)關(guān)注是否存在覆蓋空洞、系統(tǒng)過載、尋呼丟失、尋呼信道功率配比低等方面的優(yōu)化記錄。,信息收集,參數(shù)配置和尋呼相關(guān)的參數(shù)如下，優(yōu)化前要注意收集：CN尋呼重發(fā)次數(shù)、尋呼時間間隔；UTRAN尋呼重發(fā)次數(shù)、尋呼時間間隔；DRX尋呼周期系數(shù)k（DRX尋呼周期=2k）；一個PICH幀包含的尋呼指示數(shù)目NP；PICH、PCH信道功率配比；CN是否使用全局尋呼；CN尋呼使用的UEID（是IMSI還是TMSI、PTMSI）；,確定優(yōu)化目標(biāo),確定優(yōu)化KPI目標(biāo)：位置區(qū)尋呼成功率路由區(qū)尋呼成功率“位置區(qū)尋呼成功率”和“路由區(qū)尋呼成功率”這兩個KPI指標(biāo)要達(dá)到優(yōu)化要求，如尋呼成功率達(dá)到86%以上。,第一章尋呼問題的分析流程,第一節(jié)分析流程第二節(jié)信息收集第三節(jié)問題定位第四節(jié)優(yōu)化驗證,問題定位,確定定位方向?qū)ず魡栴}優(yōu)化目的是保證尋呼的KPI指標(biāo)，UE能否成功回尋呼響應(yīng)直接關(guān)系到尋呼的KPI指標(biāo)。從這個角度上看，尋呼問題可以分為以下三個方向：尋呼消息根本沒有在空口下發(fā)；最大的可能是尋呼丟失，也是尋呼過程中最常見的問題。具體分析見隨后兩節(jié)。尋呼消息下發(fā)，UE沒有收到或者是收到錯誤的尋呼消息；按照用戶投訴的情況具體區(qū)分，如果只是UE作被叫有問題，可能是PICH和PCH的功率配比過低或手機(jī)性能有問題；如果UE主叫被叫都有問題，可能該區(qū)域存在信號覆蓋盲區(qū)。UE收到尋呼后回尋呼響應(yīng)失敗；屬于接入失敗的問題，解決方法參考“接入過程問題分析”。,問題定位,確定定位方向在尋呼問題定位過程中，可以通過分析尋呼話統(tǒng)、告警和用戶投訴來確定。尋呼丟失一般發(fā)生在話務(wù)量高的時間段，查看CN的話統(tǒng)“位置區(qū)尋呼成功率”和“路由區(qū)尋呼成功率”，如果這兩個指標(biāo)總是在話務(wù)量高的時間段表現(xiàn)得比較低，用戶投訴也是集中在這一時間段，則說明尋呼丟失較嚴(yán)重，需要重點(diǎn)分析尋呼丟失的原因。同時查看CN是否有RNC過載告警、RNC是否有流控告警，如果有這些告警存在說明尋呼丟失的可能性很大。如果這兩個指標(biāo)低的事件在時間上近似均勻分布，用戶投訴具有地域性，就要檢查除“尋呼丟失”外的原因了，如尋呼信道配比、信號覆蓋、手機(jī)性能等。進(jìn)一步分析尋呼問題需要到現(xiàn)場進(jìn)行撥測分析，時間選擇在話務(wù)量高的時間段，地點(diǎn)選擇用戶投訴集中的區(qū)域，撥測過程中可以在CN和RNC的維護(hù)臺上跟蹤尋呼消息的下發(fā)和UE回尋呼響應(yīng)的過程。,問題定位,尋呼丟失原因?qū)ず粼谝韵虑闆r下會丟失：RNC系統(tǒng)處于尋呼流控狀態(tài)。當(dāng)RNC檢查到CPU占有率或者消息隊列占有率達(dá)到預(yù)先設(shè)置的門限時，就會觸發(fā)尋呼流控，在尋呼流控狀態(tài)下尋呼消息無條件丟棄。PCH容量限制。以PCH目前的編碼方式，一個TTI只能傳輸240bits，如果使用IMSI尋呼，同一尋呼時刻只能尋呼3個UE；如果使用TMSI和PTMSI尋呼，同一尋呼時刻只能尋呼5個UE；如果在同一尋呼時刻尋呼UE的個數(shù)超過系統(tǒng)的處理能力，就會造成尋呼丟失。其它原因，如IUB口傳輸故障和設(shè)備故障等，這類故障發(fā)生幾率小，會有相應(yīng)告警伴隨。,問題定位,丟失原因分析導(dǎo)致尋呼丟失的直接原因是系統(tǒng)過載、尋呼信道過載等，進(jìn)一步地深入分析其原因可能是CN和RNC使用了不適當(dāng)?shù)膶ず舨呗裕饕憩F(xiàn)在以下幾個方面：尋呼區(qū)域規(guī)劃過大CN尋呼重發(fā)次數(shù)和時間間隔設(shè)置不合理UTRAN尋呼重發(fā)次數(shù)和時間間隔設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼周期系統(tǒng)設(shè)置不合理NP值設(shè)置不合理CN使用的UE標(biāo)識不合理詳細(xì)的分析參見后面的案例。,問題定位,其它原因分析可能存在的其它方面的原因有：尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題詳細(xì)的分析參見后面的案例。,第一章尋呼問題的分析流程,第一節(jié)分析流程第二節(jié)信息收集第三節(jié)問題定位第四節(jié)優(yōu)化驗證,問題優(yōu)化,針對各個專題的尋呼問題優(yōu)化方法詳見第二章節(jié)的描述。,優(yōu)化驗證,在對網(wǎng)絡(luò)實(shí)施了優(yōu)化調(diào)整后，需要驗證優(yōu)化的結(jié)果：話統(tǒng)：查看“位置區(qū)尋呼成功率”和“路由區(qū)尋呼成功率”是否達(dá)到預(yù)定的優(yōu)化目標(biāo)；告警：查看CN是否有“RNC過載”告警，RNC是否有流控告警；用戶投訴：在一段時間內(nèi)是否有用戶被叫投訴；撥測：選擇話務(wù)高峰期和用戶投訴地測試手機(jī)被叫成功率，撥測不需要接通，電話只需要聽回鈴音或提示音即可。,課程內(nèi)容,T,第一章尋呼問題的分析流程第二章尋呼問題的典型案例,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,尋呼區(qū)域規(guī)劃過大,現(xiàn)象與分析CN通常在一個尋呼區(qū)域（位置區(qū)或者路由區(qū)）對目標(biāo)UE進(jìn)行尋呼，這種尋呼又稱作本局尋呼。對CS域業(yè)務(wù)來說，CN使用位置區(qū)來識別和尋呼UE，位置區(qū)被定義為移動終端在不更新VLR的情況下可以自由移動的區(qū)域，一個位置區(qū)可以涵蓋一個或幾個小區(qū)。對PS域業(yè)務(wù)來說，CN使用routingarea來識別和尋呼UE，RA定義為在特定操作模式下，移動終端不需要更新SGSN的情況下可以自由移動的區(qū)域，一個RA可以包含一個或幾個小區(qū)。路由區(qū)和位置區(qū)的關(guān)系采用了GSM中定義的關(guān)系，即：路由區(qū)可以和位置區(qū)的大小相等，或者只是某個位置區(qū)的子集。,尋呼區(qū)域規(guī)劃過大,現(xiàn)象與分析如果尋呼區(qū)域規(guī)劃過大，網(wǎng)絡(luò)尋呼移動臺的同一尋呼消息會在許多小區(qū)中發(fā)送，會導(dǎo)致尋呼信道負(fù)荷過重，同時增加Iub接口上的信令流量。如果小區(qū)的尋呼信道在一段時間內(nèi)負(fù)荷過重，會導(dǎo)致尋呼該小區(qū)UE的尋呼消息被丟掉，造成在服務(wù)區(qū)內(nèi)的開機(jī)用戶不能被尋呼到（用戶不在服務(wù)區(qū)）問題。反之，如果尋呼區(qū)域規(guī)劃過小，那么會造成用戶在移動過程進(jìn)行頻繁的位置更新，從而增加系統(tǒng)的信令流量，頻繁的位置更新會影響手機(jī)的待機(jī)時間。對于建網(wǎng)初期，PS業(yè)務(wù)尋呼需求不大，此時RA不需要刻意劃分的過小，可按照n1來規(guī)劃。隨著網(wǎng)絡(luò)的不斷演進(jìn)，PS業(yè)務(wù)的需求不斷增多，這時候可適當(dāng)減小RA的大小。優(yōu)化措施對網(wǎng)絡(luò)容量或?qū)ず袅看笥谝欢ㄩT限的位置區(qū)進(jìn)行位置區(qū)分裂，可以有效降低尋呼消息流量。,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,CN尋呼參數(shù)設(shè)置不合理,現(xiàn)象與分析CN為保證尋呼成功率，會在IU接口重發(fā)尋呼消息，CN尋呼重發(fā)次數(shù)和時間間隔是可以配置的。尋呼重發(fā)造成尋呼量成倍增加，浪費(fèi)下行信道資源。CN的尋呼重發(fā)配置應(yīng)該和UTRAN協(xié)調(diào)起來。CN的尋呼重發(fā)是為防止第一次尋呼手機(jī)未正常響應(yīng)而再次發(fā)起尋呼，提高尋呼成功率和接通率。但是GSM網(wǎng)上數(shù)據(jù)表明，重發(fā)尋呼的成功率比較低，特別是二次及二次以上重發(fā)，對尋呼成功率和接通率的貢獻(xiàn)很小。經(jīng)驗數(shù)據(jù)表明：一般第一次尋呼成功率接近86%，重復(fù)尋呼成功率1.8%，其中重發(fā)尋呼成功大部分為二次尋呼成功，三次尋呼成功的次數(shù)按遞減的規(guī)律計算，其尋呼成功率估計在0.2%以下。WCDMA的尋呼機(jī)制和GSM基本類似，從網(wǎng)上統(tǒng)計數(shù)據(jù)可以看出，CN尋呼次數(shù)太多對尋呼成功率的貢獻(xiàn)很小，相反增加了系統(tǒng)負(fù)荷。,CN尋呼參數(shù)設(shè)置不合理,現(xiàn)象與分析CN的尋呼時間間隔不宜過短。CN通過IU接口發(fā)尋呼消息給RNC，RNC根據(jù)尋呼消息帶的IMSI計算出尋呼時刻，并安排在最近一個尋呼周期對應(yīng)的尋呼時刻下發(fā)。目前我司的RNC也采用了尋呼重發(fā)機(jī)制，缺省是重發(fā)1次，重發(fā)時間間隔是一個尋呼周期。從上述分析來看，RNC從收到CN的尋呼到下發(fā)到空口的最大時間間隔是一個尋呼周期，在RNC重發(fā)1次的情況下，CN的尋呼時間間隔要大于兩個尋呼周期為宜。目前我司實(shí)現(xiàn)的尋呼周期是2.56s，如果CN的尋呼時間間隔大于2.56s小于5.12，在CN重發(fā)尋呼到來時，RNC還沒有完成尋呼的重發(fā)，RNC處理的結(jié)果是在緊接著的下一個尋呼周期安排尋呼，這樣實(shí)際上只發(fā)了3個尋呼消息，沒有達(dá)到預(yù)計的4個尋呼消息，造成了尋呼消息在無形中丟失。,CN尋呼參數(shù)設(shè)置不合理,優(yōu)化措施CN的尋呼重發(fā)配置應(yīng)該和UTRAN互相配合。在UTRAN尋呼重發(fā)1次的情況下，建議CN配置重發(fā)1次（總共發(fā)2次），重發(fā)時間間隔大于兩個尋呼周期。減少尋呼重發(fā)次數(shù)同時增大尋呼時間間隔，整體尋呼無響應(yīng)的時間基本保持不變，不會影響MSC尋呼無響應(yīng)時上報語音提示的時間間隔。CN尋呼時間間隔和重發(fā)次數(shù)可以通過軟參進(jìn)行配置。,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,UTRAN尋呼參數(shù)設(shè)置不合理,現(xiàn)象與分析為了減少Iu口尋呼消息流量，增加UE接收到尋呼消息的可能性，UTRAN可以重復(fù)發(fā)送尋呼消息，UTRAN尋呼重發(fā)配置要與CN尋呼重發(fā)相配合。由于尋呼總是在固定的尋呼時刻（一個尋呼周期內(nèi)）下發(fā)，UTRAN尋呼時間間隔為一個尋呼周期的整數(shù)倍，一般為一個尋呼周期，所以可以通過調(diào)整DRC尋呼周期系數(shù)k，來調(diào)整UTRAN的尋呼重發(fā)時間間隔。UTRAN尋呼重發(fā)次數(shù)不宜過大，否則加上Iu口尋呼重發(fā)，Uu口尋呼信道負(fù)荷會劇增。另外，目前UTRAN在MACC層實(shí)現(xiàn)，MACC不識別具體的RRC消息，即使UE回了尋呼響應(yīng)消息，MACC還會繼續(xù)重發(fā)尋呼。優(yōu)化措施尋呼重發(fā)次數(shù)保持目前的缺省配置比較合理。,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,CN使用了全網(wǎng)尋呼,現(xiàn)象與分析出于提高來話接通率的考慮，CN側(cè)一般可配置全網(wǎng)尋呼。這種尋呼方式的最大特點(diǎn)是尋呼跨越位置區(qū)的概念，針對全CN下掛的所有的UTRAN發(fā)起。這種情況下的尋呼流量更大，特別是當(dāng)CN下掛多個位置區(qū)的時候，容易導(dǎo)致容量較小的位置區(qū)出現(xiàn)過載，并且長時間無法恢復(fù)。優(yōu)化措施CN應(yīng)該避免采用全局尋呼。根據(jù)GSM網(wǎng)上應(yīng)用經(jīng)驗，CN的全網(wǎng)尋呼是造成容量較小的位置區(qū)出現(xiàn)過載的重要原因。CN的全局尋呼僅在VLR記錄UE位置區(qū)錯誤的情況有用，而這種情況極少發(fā)生，而且一旦發(fā)生，則表示系統(tǒng)出現(xiàn)重大故障。,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,DRX尋呼參數(shù)設(shè)置不合理,現(xiàn)象與分析當(dāng)UE處在IDLE和PCH狀態(tài)時，為了減少功率的消耗UE會利用不連續(xù)接收技術(shù)DiscontinuousReception（DRX）。根據(jù)協(xié)議TS25.304，尋呼周期長度（DRXcyclelength）=MAX（2k，PBP）。其中：K為”DRXcyclelengthcoefficient”，PBP為尋呼塊周期”PagingBlockPeriodicity”，對于FDD，PBP=1，所以DRXcyclelength=2K。UE的DRX尋呼有三個來源：系統(tǒng)消息、CN的尋呼消息、UTRAN的UU口信令，并且CS、PS的處理方式也不一樣。對于PS域，DRX尋呼周期系數(shù)由UE和SGSN通過NAS層消息（attach過程）協(xié)商，不管UE處于IDLE或者是connect都以協(xié)商數(shù)據(jù)為準(zhǔn)，如果協(xié)商失敗則使用CS域的尋呼系數(shù)。對于CS域，如果UE在IDLE狀態(tài)下，DRX尋呼周期系數(shù)使用系統(tǒng)消息、CN的尋呼消息中的最小值，如果UE在連接狀態(tài)，DRX尋呼周期系數(shù)使用系統(tǒng)消息、CN的尋呼消息、UTRAN的UU口信令中的最小值。,DRX尋呼參數(shù)設(shè)置不合理,現(xiàn)象與分析DRX尋呼周期系數(shù)K的設(shè)置，主要考慮以下因素：DRX尋呼周期系數(shù)K決定了DRX周期長度，K值越大，DRX周期就越長，UE功耗會降低，但是也帶來了UE尋呼周期變長。如果K值過小，尋呼周期變小，UE處理尋呼開銷和功耗都會增加。協(xié)議給出取值范圍為212，目前建議取值8，尋呼周期為2.56秒。以PCH目前的編碼方式，一個TTI只能傳輸240bits，如果使用IMSI尋呼，同一尋呼時刻只能尋呼3個UE；如果使用TMSI尋呼，同一尋呼時刻只能尋呼5個UE。如果在同一尋呼時刻尋呼UE的個數(shù)超過系統(tǒng)的處理能力，就會造成尋呼丟失的情況。如果K值設(shè)置過小，尋呼周期變短，計算出來UE的尋呼時刻相同的概率增大，尋呼丟失的概率也相應(yīng)增大。由于UTRAN尋呼重發(fā)時間間隔是一個尋呼周期，所以DRX尋呼周期系數(shù)K的設(shè)置也要考慮到UTRAN尋呼重發(fā)時間間隔，要和CN尋呼重發(fā)情況配合設(shè)置。,DRX尋呼參數(shù)設(shè)置不合理,優(yōu)化措施K值下限的設(shè)置要考慮到節(jié)省UE功耗和減小UE尋呼時刻相同的概率，K值上限的設(shè)置要考慮到UTRAN尋呼重發(fā)時間間隔。在實(shí)際設(shè)置過程中，K值一般設(shè)置位于212中間的值，如5、6、7、8，尋呼周期分別對應(yīng)320ms、640ms、1280ms、2560ms。假設(shè)CN尋呼重發(fā)次數(shù)為1（總共發(fā)送兩次尋呼），間隔為2s，那么UTRAN重發(fā)次數(shù)和間隔的設(shè)置應(yīng)該遵從如下規(guī)律：1、如果UTRAN重發(fā)次數(shù)為0次（UTRAN不重發(fā)），UTRAN的DRX周期應(yīng)小于CN重發(fā)間隔（2s），即此時的K值應(yīng)該設(shè)置為7或8（1.28s,2.56s）比較合適，設(shè)置為8主要是考慮Iu/IuB尋呼流控時尋呼的丟失；2、如果UTRAN重發(fā)次數(shù)為1，UTRAN的DRX周期應(yīng)小于CN重發(fā)間隔的一半（1s），即此時的K值應(yīng)該設(shè)置為6或7（0.64,1.28s）比較合適，設(shè)置為7主要是考慮Iu/IuB尋呼流控時尋呼的丟失；,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,NP值設(shè)置不合理,現(xiàn)象與分析Np是尋呼指示信道PICH在一幀中下發(fā)的PI尋呼指示數(shù)，該參數(shù)在系統(tǒng)消息5中通過NumberofPIperframe指示。UE會在確定的尋呼時機(jī)接收PICH幀，然后找到對應(yīng)的PI指示位（第q個PI指示），只有相應(yīng)的PI指示位有效，UE才會去解調(diào)對應(yīng)的S-CCPCH幀。Np在實(shí)際網(wǎng)絡(luò)中的意義：該參數(shù)將所有的IMSI分成了Np組，每一個組中所有的IMSI使用同一個PI。Np設(shè)置過小，則每組中對應(yīng)的UE數(shù)目較多，對每個IMSI而言，PI指示出現(xiàn)的概率增大，被喚醒的次數(shù)越多，對節(jié)省UE功耗不利；Np設(shè)置過大，則每組中對應(yīng)的IMSI數(shù)目較少，對每個IMSI而言，PI指示出現(xiàn)的概率也較小，被喚醒的次數(shù)也較少，但Np越大，每個PI對應(yīng)的bit數(shù)目減少，對UE的PICH解調(diào)性能要求越高。優(yōu)化措施Np取值范圍在（18，36，72，144），要根據(jù)當(dāng)前網(wǎng)絡(luò)的用戶數(shù)的多少確定，一般用戶多Np取值大一些，用戶少Np取值小一些，實(shí)際網(wǎng)絡(luò)中可以取中間值36或72。,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,CN尋呼使用的UE標(biāo)識,現(xiàn)象與分析網(wǎng)絡(luò)可以使用尋呼類型1消息同時在空口尋呼多個UE，由于PCH容量的限制，UE的個數(shù)和尋呼消息中使用的UE標(biāo)識密切相關(guān)，也就是說UE標(biāo)識影響了尋呼信道的容量。相對于CN發(fā)起尋呼的情況，UTRAN發(fā)起尋呼的概率要小得多，這里只考慮CN發(fā)起尋呼的情況：UE處于IDLE狀態(tài)，CN使用IMSI進(jìn)行尋呼，只能同時尋呼3個UE；UE處于IDLE狀態(tài)，CN使用TMSI或者PTMSI進(jìn)行尋呼，只能同時尋呼5個UE；UE處于CELL_PCH或URA_PCH狀態(tài)，不管CN使用什么尋呼標(biāo)識，UTRAN使用U-RNTI進(jìn)行尋呼，只能同時尋呼5個UE。從上述分析可以看出，CN使用UE臨時標(biāo)識TMSI和PTMSI可以增加PCH的容量。優(yōu)化措施CN優(yōu)化使用UE臨時標(biāo)識TMSI和PTMSI進(jìn)行尋呼，可以通過軟參進(jìn)行調(diào)整。,第二章尋呼問題的典型案例,尋呼區(qū)域規(guī)劃過大CN尋呼參數(shù)設(shè)置不合理UTRAN尋呼參數(shù)設(shè)置不合理CN使用了全網(wǎng)尋呼DRX尋呼參數(shù)設(shè)置不合理NP值設(shè)置不合理CN尋呼使用的UE標(biāo)識IMSIATTACH/DETACH功能尋呼類信道功率配比過低存在覆蓋盲區(qū)手機(jī)性能問題,IMSIATTACH/DETACH功能,現(xiàn)象與分析當(dāng)UE開機(jī)注冊成功后，MSC/VLR置用戶狀態(tài)為ATTACH，IMSIDETACH即移動用戶關(guān)機(jī)，MS發(fā)起DETACH的流程，MSC/VLR置用戶狀態(tài)為IMSI分離，該流程一般不通知HLR。UE通過接收系統(tǒng)消息1確定能否使用IMSIATTACH和DETACH過程。GsmMAPIE有兩個octer組成，第一個octer是T3212，第二個octer的bit1是ATT標(biāo)識，“0”表示網(wǎng)絡(luò)不允許UE使用IMSIATTACH和DETACH過程，“1”表示允許。下圖配置的“0a01”表示T3212是60分鐘，允許UE使用IMSIATTACH和DETACH過程。,IMSIATTACH/DETACH功能,現(xiàn)象與分析優(yōu)