1、華為技術(shù)有限公司Huawei Technologies Co. Ltd.產(chǎn)品版本密級(jí)V100R001內(nèi)部公開產(chǎn)品名稱: WCDMA RNP共25頁(yè)WCDMA RNO尋呼問(wèn)題分析指導(dǎo)書(僅供內(nèi)部使用）For internal use onlyHUAWEI華為技術(shù)有限公司Huawei Technologies Co., Ltd.版權(quán)所有侵權(quán)必究All rights reserved目錄1概述. 82尋呼問(wèn)題分析過(guò)程. 92.1 問(wèn)題分析流程. 92.2 網(wǎng)絡(luò)信息收集. 102.2.1 話統(tǒng) . 102.2.2 告警 . 122.2.3 用戶投訴 . 132.2.4 網(wǎng)絡(luò)規(guī)劃優(yōu)化歷史記錄 . 132

2、.2.5 無(wú)線參數(shù)配置 . 142.3 確定優(yōu)化目標(biāo). 142.4 尋呼問(wèn)題定位. 142.4.1 確定基本定位方向 . 142.4.2 尋呼丟失直接原因 . 152.4.3 尋呼丟失原因深入分析 . 152.4.4 其它原因分析 . 162.5 尋呼問(wèn)題優(yōu)化. 162.6 優(yōu)化驗(yàn)證. 163尋呼典型問(wèn)題分析. 163.1 尋呼區(qū)域規(guī)劃過(guò)大. 163.1.1 問(wèn)題分析 . 163.1.2 優(yōu)化措施 . 183.2 CN尋呼重發(fā)次數(shù)和時(shí)間間隔設(shè)置不合理. 183.2.1 問(wèn)題分析 . 183.2.2 優(yōu)化措施 . 193.3 UTRAN尋呼重發(fā)次數(shù)和時(shí)間間隔設(shè)置不合理 . 193.3.1 問(wèn)題分

3、析 . 193.3.2 優(yōu)化措施 . 193.4 CN使用了全網(wǎng)尋呼 . 193.4.1 問(wèn)題分析 . 193.4.2 優(yōu)化措施 . 193.5 DRX尋呼周期系數(shù)設(shè)置不合理. 203.5.1 問(wèn)題分析 . 203.5.2 優(yōu)化措施 . 213.6 NP值設(shè)置不合理 . 213.6.1 問(wèn)題分析 . 213.6.2 優(yōu)化措施 . 213.7 CN尋呼使用的UE標(biāo)識(shí) . 223.7.1 問(wèn)題分析 . 223.7.2 優(yōu)化措施 . 223.8 UTRAN應(yīng)激活I(lǐng)MSI ATTACH和DETACH功能 . 223.8.1 問(wèn)題分析 . 223.8.2 優(yōu)化措施 . 233.9 尋呼類信道功率配比過(guò)低

4、. 233.9.1 問(wèn)題分析 . 233.9.2 優(yōu)化措施 . 233.10存在覆蓋盲區(qū) . 243.10.1問(wèn)題分析. 243.10.2優(yōu)化措施. 243.11手機(jī)性能問(wèn)題 . 243.11.1問(wèn)題分析. 243.11.2優(yōu)化措施. 244遺留問(wèn)題. 24圖目錄圖1典型UE被叫流程 . 9圖2尋呼問(wèn)題分析流程 . 10圖3系統(tǒng)消息1解析 . 23表目錄表1RNC尋呼話統(tǒng)指標(biāo) . 11 表2UMSC尋呼話統(tǒng)指標(biāo) . 12 表3SGSN尋呼話統(tǒng)指標(biāo) . 12 表4用戶投訴信息表 . 13 表5CN ID使用IMSI時(shí)尋呼區(qū)域計(jì)算結(jié)果表 . 17 表6IMSI ATTACH和DETACH標(biāo)識(shí). 2

5、2WCDMA RNO 尋呼問(wèn)題 分析指導(dǎo)書關(guān)鍵詞：尋呼、尋呼區(qū)域、尋呼重發(fā)摘要：本文首先闡述了尋呼問(wèn)題解決的一般流程，然后針對(duì)尋呼過(guò)程可能會(huì)出現(xiàn)的典型問(wèn)題進(jìn)行 詳細(xì)分析并給出其優(yōu)化措施?？s略語(yǔ)清單：Abbreviations縮略語(yǔ)Full spelling英文全名Chinese explanation中文解釋DRXDiscontinuous Reception非連續(xù)接收LALocation Area位置區(qū)PCHPaging Channel尋呼信道PIPaging Indication尋呼指示PICHPage Indication Channel尋呼指示信道RARoute Area路由區(qū)RANR

6、adio Access Network無(wú)線接入網(wǎng)絡(luò)RNCRadio Network Controller無(wú)線網(wǎng)絡(luò)控制器RNORadio Network Optimization無(wú)線網(wǎng)絡(luò)優(yōu)化WCDMAWideband Code Division Multiple Access寬帶碼分復(fù)用1 概述如果網(wǎng)絡(luò)側(cè)需要主動(dòng)聯(lián)系處于空閑模式、CELL_PCH 或者URA_PCH狀態(tài)的UE，就要發(fā)起尋呼流程，尋呼是網(wǎng)絡(luò)聯(lián)系UE的重要途徑。和其它流程相比較，尋呼流程在無(wú) 線網(wǎng)絡(luò)中表現(xiàn)出頻率高、流量大、突發(fā)性強(qiáng)等特點(diǎn)，尋呼性能關(guān)系到整個(gè)無(wú)線網(wǎng)絡(luò)的性 能。所以研究尋呼問(wèn)題對(duì)無(wú)線網(wǎng)絡(luò)性能具有很強(qiáng)的現(xiàn)實(shí)意義。從UE接收

7、尋呼消息的角度來(lái)看，尋呼消息分為PAGING TYPE1和PAGING TYPE2， 由UTRAN決定發(fā)送給UE的尋呼類型。PAGING TYPE1是通過(guò)PCCH邏輯信道來(lái)尋呼處 在IDLE，CELL_PCH，URA_PCH狀態(tài)的UE。PAGING TYPE2是通過(guò)DCCH來(lái)尋呼處在 CELL_FACH，CELL_DCH狀態(tài)的UE。PAGING TYPE1是本文討論的重點(diǎn)，PAGING TYPE2可以作為普通的RRC信令處理，本文不作討論。網(wǎng)絡(luò)側(cè)會(huì)在以下情況下發(fā)起尋呼：9UE被叫：為了建立一次呼叫，核心網(wǎng)（CN）通過(guò)Iu接口向UTRAN發(fā)送尋呼消 息，UTRAN則將CN尋呼消息通過(guò)Uu接口上的

8、尋呼過(guò)程發(fā)送給UE，使得被尋 呼的UE發(fā)起與CN的信令連接建立過(guò)程。9小區(qū)系統(tǒng)消息更新：當(dāng)系統(tǒng)消息發(fā)生改變時(shí)，UTRAN為了通知處在空閑模式、 CELL_PCH和URA_PCH狀態(tài)下的UE進(jìn)行系統(tǒng)消息更新會(huì)觸發(fā)尋呼過(guò)程，以使 UE讀取更新后的系統(tǒng)信息。對(duì)于處在CELL_FACH狀態(tài)的UE，為了通知它進(jìn) 行相應(yīng)的系統(tǒng)更新需要通過(guò)BCCH發(fā)送SYSTEM INFORMATION CHANGE INDICATION消息（由于V1.2版本不支持該消息，所以對(duì)CELL_FACH狀態(tài)的 UE不做處理）。9UE狀態(tài)遷移：為了觸發(fā)處于CELL_PCH，URA_PCH狀態(tài)下的UE進(jìn)行狀態(tài)遷 移（比如遷移到CEL

9、L_FACH狀態(tài)），UTRAN會(huì)進(jìn)行一次尋呼流程，作為對(duì) 該尋呼的一種應(yīng)答形式，UE會(huì)相應(yīng)的發(fā)起一次小區(qū)更新或URA更新。一個(gè)典型的由尋呼引起的被叫流程如圖 1 所示：CN發(fā)尋呼消息給UTRAN，UTRAN 收到尋呼消息后計(jì)算出尋呼時(shí)刻并獲取目標(biāo)小區(qū)，在尋呼時(shí)刻到來(lái)時(shí)將尋呼消息在空口 下發(fā)。UE尋呼成功的標(biāo)志是CN收到UE的尋呼響應(yīng)消息，整個(gè)過(guò)程包括尋呼下發(fā)和UE 接入等過(guò)程，UE接入過(guò)程不是本文討論的范圍，請(qǐng)參考接入過(guò)程指導(dǎo)書。尋呼過(guò)程中 可能會(huì)存在種種問(wèn)題導(dǎo)致目標(biāo)UE不能正確收到尋呼消息，如在網(wǎng)絡(luò)群發(fā)短消息和全文 尋呼時(shí)，不合理的尋呼策略會(huì)使得尋呼信道擁塞從而造成尋呼消息大量丟失，嚴(yán)重情形

10、 下還會(huì)造成系統(tǒng)長(zhǎng)期過(guò)載，尋呼信道功率配比過(guò)低造成尋呼成功率低。本文將對(duì)這些導(dǎo) 致尋呼異常的問(wèn)題進(jìn)行深入討論，并給出其解決方法。UE NASUE ASNSSMSCpagingRR_PAING_INDpagingRANAPRANAPRR_EST_REQ (PAGING RESPONSE)RRC連接建立過(guò)程AUTHENTICATION REQUESTINITIAL_DIRECT_TRANSFER (PAGING RESPONSE)AUTHENTICATION RESPONSERR_SECURITY_CONTROL_REQ (IK CK)加密模式控制SETUPCALL CONFIRMRAB 建立過(guò)程

11、ALERTCONNECTCONNECT ACKNOW LEDGE圖 1 典型UE被叫流程本文結(jié)構(gòu)的基本結(jié)構(gòu)如下：1、概述：簡(jiǎn)單介紹尋呼發(fā)起的時(shí)機(jī)、尋呼流程、尋呼常見問(wèn)題等，引出全文；2、尋呼問(wèn)題分析過(guò)程：論述尋呼問(wèn)題的分析流程，如何逐步深入分析尋呼問(wèn)題， 每一步需要做的具體工作。3、尋呼典型問(wèn)題分析：分析影響尋呼常見的典型問(wèn)題，包括問(wèn)題的現(xiàn)象，原理和 優(yōu)化方法。4、遺留問(wèn)題：本文暫時(shí)無(wú)法解決的問(wèn)題。2 尋呼問(wèn)題分析過(guò)程2.1 問(wèn)題分析流程尋呼問(wèn)題分析流程如圖 2 所示，和網(wǎng)絡(luò)問(wèn)題一般分析方法類似，尋呼問(wèn)題分析步 驟大體分為四個(gè)步驟，各個(gè)步驟的主要工作是：網(wǎng)絡(luò)信息收集：收集網(wǎng)絡(luò)與尋呼相關(guān)話統(tǒng)、告

12、警、用戶投訴、網(wǎng)絡(luò)規(guī)劃和優(yōu)化記錄、 網(wǎng)絡(luò)參數(shù)配置等信息；確定優(yōu)化目標(biāo)：確定尋呼問(wèn)題優(yōu)化的KPI指標(biāo)； 尋呼問(wèn)題定位：定位導(dǎo)致尋呼問(wèn)題的原因；尋呼問(wèn)題優(yōu)化：根據(jù)定位結(jié)果采用相應(yīng)的優(yōu)化調(diào)整措施；優(yōu)化驗(yàn)證：驗(yàn)證優(yōu)化后的KPI指標(biāo)是否達(dá)到要求以及其它尋呼相關(guān)信息是否正常。網(wǎng)絡(luò)信息收集確定優(yōu)化目標(biāo)尋呼問(wèn)題定位尋呼問(wèn)題優(yōu)化優(yōu)化驗(yàn)證NO是否達(dá)到優(yōu)化目標(biāo)？YESEND圖 2 尋呼問(wèn)題分析流程2.2 網(wǎng)絡(luò)信息收集網(wǎng)絡(luò)信息收集是尋呼問(wèn)題分析的第一步，優(yōu)化人員要獲取待優(yōu)化網(wǎng)絡(luò)中與尋呼相關(guān) 的話統(tǒng)、用戶投訴、告警、網(wǎng)絡(luò)規(guī)劃優(yōu)化歷史記錄、無(wú)線參數(shù)配置等等信息，為后續(xù)進(jìn) 一步的深入分析做準(zhǔn)備。2.2.1 話統(tǒng)尋呼相關(guān)的話

13、統(tǒng)指標(biāo)可以根據(jù)不同的尋呼區(qū)域分別在RNC、UMSC、SGSN話統(tǒng)臺(tái) 上觀測(cè)，RNC話統(tǒng)對(duì)應(yīng)一個(gè)RNC區(qū)域，UMSC話統(tǒng)對(duì)應(yīng)一個(gè)位置區(qū)，SGSN話統(tǒng)對(duì)應(yīng)一 個(gè)路由區(qū)。在實(shí)際話統(tǒng)分析過(guò)程中以分析CN的話統(tǒng)為主，并把RNC和CN的話統(tǒng)數(shù)據(jù)結(jié) 合起來(lái)分析。如果話統(tǒng)臺(tái)上沒有尋呼相關(guān)的話統(tǒng)任務(wù)運(yùn)行，需要聯(lián)系局方人員創(chuàng)建尋呼 話統(tǒng)任務(wù)。下面在我司尋呼話統(tǒng)實(shí)現(xiàn)的基礎(chǔ)上分別討論RNC、UMSC、SGSN與尋呼相 關(guān)的話統(tǒng)。RNC的話統(tǒng)情況如表1 所示，需要關(guān)注CN_PAGE_IDLE_UE_SUCC_RATE（CN發(fā) 起的尋呼空閑狀態(tài)UE的尋呼成功率）和UTRAN_PAGE1_SUCC_RATE（UTRAN發(fā)起

14、尋呼類型1的尋呼成功率），這兩個(gè)指標(biāo)基本表征了RNC對(duì)應(yīng)尋呼區(qū)域的尋呼成功率。 CN_PAGE_IDLE_UE_SUCC_RATE 從 CN 的 角度考察 了尋呼的 成功率， UTRAN_PAGE1_SUCC_RATE除了包含CN尋呼情況外，還包含UTRAN系統(tǒng)消息更新 和UE狀態(tài)遷移兩種情況（這時(shí)UE的尋呼響應(yīng)消息是小區(qū)更新）。這兩個(gè)指標(biāo)可以用來(lái) 分析一個(gè)RNC區(qū)域的尋呼性能，一個(gè)RNC區(qū)域一般包括一個(gè)或多個(gè)位置區(qū)。表1RNC尋呼話統(tǒng)指標(biāo)話統(tǒng)指標(biāo)名稱話統(tǒng)指標(biāo)含義話統(tǒng)指標(biāo)標(biāo)準(zhǔn)測(cè)量點(diǎn)CN_PAGE_REQ統(tǒng)計(jì)IU接口尋呼的次數(shù)收到CN發(fā)起的PAGING消息CN_PAGE_IDLE_UE_REQ統(tǒng)

15、計(jì)IU接口尋呼空閑用戶的次數(shù)收到CN發(fā)起的PAGING消息，且被尋呼的UE當(dāng)前為空閑態(tài)CN_PAGE_IDLE_UE_SUCC統(tǒng)計(jì)尋呼空閑用戶成功 的次數(shù)收到UE的RRC連接請(qǐng)求消息，且請(qǐng)求原 因 為被叫類原因 ，如 “TerminatingConversational Call”UTRAN_PAGE1_REQ統(tǒng)計(jì)由 UTRAN 側(cè)發(fā)起 的PAGING TYPE 1消息 的次數(shù)由UTRAN側(cè)發(fā)起PAGING TYPE 1消息UTRAN_PAGE1_SUCC統(tǒng)計(jì)由 UTRAN 側(cè)發(fā)起 PAGING TYPE 1消息， 收到UE成功響應(yīng)的次數(shù)UTRAN側(cè)收到UE的尋呼響應(yīng)類消息CN_PAGE_ID

16、LE_UE_SUCC_R ATE統(tǒng)計(jì)CN發(fā)起的尋呼空閑 狀態(tài)UE的尋呼成功率是計(jì)算指標(biāo)，由計(jì)算公式CN_PAGE_IDLE_UE_SUCC/ CN_PAGE_IDLE_UE_REQ得到UTRAN_PAGE1_SUCC_RATE統(tǒng)計(jì) UTRAN 發(fā)起尋呼 類型1的尋呼成功率是計(jì)算指標(biāo)，由計(jì)算公式UTRAN_PAGE1_SUCC/UTRAN_PA GE1_REQ得到UMSC尋呼相關(guān)話統(tǒng)指標(biāo)都是基于一個(gè)位置區(qū)的，如表2 所示。一般情況下，位置區(qū)不會(huì)跨RNC、BSC配置，可以統(tǒng)計(jì)一個(gè)位置區(qū)的尋呼成功率、第一次尋呼成功率、非 第一次尋呼成功率。位置區(qū)的尋呼成功率關(guān)注一個(gè)位置區(qū)的尋呼狀況，并不關(guān)心尋呼重

17、發(fā)次數(shù)，而第一次尋呼成功率、非第一次尋呼成功率關(guān)注尋呼重發(fā)次數(shù)對(duì)尋呼成功率的 影響。位置區(qū)尋呼成功率 = 第一次發(fā)尋呼次數(shù)下發(fā)尋呼無(wú)響應(yīng)消息數(shù) 第一次發(fā)尋呼次數(shù)第一次尋呼成功率 = 第一次尋呼響應(yīng)次數(shù) 第一次發(fā)尋呼次數(shù)非第一次尋呼成功率 =接口重復(fù)發(fā)尋呼次數(shù)接口重復(fù)尋呼響應(yīng)次數(shù)表2UMSC尋呼話統(tǒng)指標(biāo)話統(tǒng)指標(biāo)名稱話統(tǒng)指標(biāo)含義話統(tǒng)指標(biāo)標(biāo)準(zhǔn)測(cè)量點(diǎn)第一次發(fā)尋呼次數(shù)MSC 第一次發(fā) Paging Req 的次數(shù)MSC 向 RNC/BSC 發(fā) PAGING 消息時(shí)統(tǒng)計(jì)第一次尋呼響應(yīng)次數(shù)MSC 第一 次發(fā) Paging 消息 后，成功收到響應(yīng)次數(shù)第一次 Paging消息發(fā)出后，MSC 收到被叫發(fā)的 PAG

18、ING RESPONSE消息時(shí) 統(tǒng)計(jì)接口重復(fù)發(fā)尋呼次數(shù)MSC 不是第一次發(fā) Paging的次數(shù)MSC 向 RNC/BSC 發(fā)PAGING 消息時(shí)統(tǒng)計(jì)接口重復(fù)尋呼響應(yīng)次數(shù)MSC 非第一次發(fā) PAGING 消 息后，成功收到響應(yīng)次數(shù)非第一次 PAGING 消息發(fā)出后，MSC收到 PAGING RESPONSE 消息時(shí)統(tǒng) 計(jì)Iu接口第一次發(fā)尋呼次數(shù)Iu接口第一次發(fā)Paging次數(shù)MSC向RNC發(fā)Paging消息時(shí)統(tǒng)計(jì)Iu接口重復(fù)發(fā)尋呼次數(shù)Iu 接口非第一次發(fā) Paging 的次數(shù)MSC 向 RNC 非第一次發(fā) Paging 消息時(shí)統(tǒng)計(jì)下發(fā)尋呼無(wú)響應(yīng)次數(shù)未收到尋 呼響應(yīng) (PAGINGRESPONSE

19、)消息次數(shù)尋呼定時(shí)器超期統(tǒng)計(jì)SGSN尋呼相關(guān)話統(tǒng)指標(biāo)都是基于一個(gè)路由區(qū)的，如表3 所示，可以得到某路由區(qū)的尋呼成功率。路由區(qū)尋呼成功率 RA分組尋呼請(qǐng)求次數(shù)RA分組尋呼失敗次數(shù)RA分組尋呼請(qǐng)求次數(shù)表3SGSN尋呼話統(tǒng)指標(biāo)話統(tǒng)指標(biāo)名稱話統(tǒng)指標(biāo)含義話統(tǒng)指標(biāo)標(biāo)準(zhǔn)測(cè)量點(diǎn)每個(gè)RA分組尋呼請(qǐng)求 次數(shù)這項(xiàng)測(cè)量提供了在特定路由區(qū)中下發(fā)分組尋呼請(qǐng)求的次數(shù)，不包 括重發(fā)的消息。SGSN 發(fā)送 Iu 接口尋呼請(qǐng)求消息 （PAGING），消息中的CN Domain為PS每個(gè)RA分組尋呼失敗次數(shù)這項(xiàng)測(cè)量提供了在特定路由區(qū)中分組尋呼失敗的次數(shù)重發(fā)尋呼消息次數(shù)達(dá)到最大值在話統(tǒng)分析過(guò)程中，要重點(diǎn)關(guān)注“位置區(qū)尋呼成功率”和“路

20、由區(qū)尋呼成功率”，這 是 衡 量 尋 呼 性 能 的 注 意 KPI 指 標(biāo) 。 RNC 的 尋 呼 話 統(tǒng) 指 標(biāo) CN_PAGE_IDLE_UE_SUCC_RATE 和UTRAN_PAGE1_SUCC_RATE 可以作為分析參 考。2.2.2 告警按照目前我司的實(shí)現(xiàn)，CN和尋呼相關(guān)的告警只有“RNC過(guò)載”，當(dāng)CN接收到RNC的過(guò)載消息引發(fā)此告警。RNC為保證系統(tǒng)運(yùn)行的穩(wěn)定性，避免突發(fā)的消息風(fēng)暴對(duì)系統(tǒng) 的沖擊，對(duì)包括尋呼在內(nèi)的某些處理頻率很高的消息進(jìn)行了流控。當(dāng)RNC收到CN的尋呼消息后，判斷系統(tǒng)如果處于尋呼流控狀態(tài)，就會(huì)丟棄尋呼消息，并記錄下尋呼消息丟 失的個(gè)數(shù)。如果尋呼丟失比例達(dá)到一定的

21、門限，RNC就會(huì)向CN發(fā)Overload消息，CN就 會(huì)控制消息發(fā)送流量按照一定的步長(zhǎng)減少。如果在一定的時(shí)間內(nèi)沒有收到Overload消 息，IU的消息流量會(huì)逐步增長(zhǎng)直至恢復(fù)正常。RNC目前尋呼相關(guān)的告警是“流量控制告警”，當(dāng)RNC處于尋呼流控狀態(tài)下尋呼 消息會(huì)無(wú)條件丟失。當(dāng)單板子系統(tǒng)的CPU占用率或者單板子系統(tǒng)的消息包占用率超過(guò)門 限時(shí)系統(tǒng)切換到流控狀態(tài)，并會(huì)產(chǎn)生流量控制告警。當(dāng)系統(tǒng)從流控狀態(tài)恢復(fù)正常工作狀 態(tài)時(shí)，會(huì)產(chǎn)生流量控制恢復(fù)告警。但是發(fā)生“流量控制告警”不一定會(huì)丟尋呼，因?yàn)?RNC對(duì)不同的流控對(duì)象（尋呼、串口打印、消息跟蹤等）有不同的流控門限，只要有 流控發(fā)生就會(huì)告警，但是只有尋呼流

22、控發(fā)生才會(huì)丟尋呼。2.2.3 用戶投訴如果尋呼消息丟失導(dǎo)致手機(jī)不能做被叫，主叫用戶會(huì)聽到系統(tǒng)提示音“用戶不在服 務(wù)區(qū)”。可以從局方1860客服中心了解用戶投訴情況或直接聯(lián)系投訴人了解不在服務(wù)區(qū) 發(fā)生情況，要重點(diǎn)關(guān)注手機(jī)被叫失敗的情況，需要收集的信息如表4 所示但不限于這些內(nèi)容【5】：表4用戶投訴信息表時(shí)間投訴用戶姓名投訴用戶號(hào)碼被叫用戶號(hào)碼被叫手機(jī)類型投訴地點(diǎn)是否經(jīng)常發(fā)生過(guò)程描述整理投訴信息尋找規(guī)律觀察是否存在下屬情況：9是否白天忙時(shí)和夜里閑時(shí)都發(fā)生。如果尋呼失敗在話務(wù)高峰，重點(diǎn)分析尋呼擁 塞的情形，如果不是在話務(wù)高峰，要分析其它因素；9是否被叫手機(jī)類型相同?？赡艽嬖谑謾C(jī)自身問(wèn)題；9是否投訴地

23、點(diǎn)集中?？赡苁且?yàn)樾盘?hào)覆蓋問(wèn)題； 找到投訴的規(guī)律能加快問(wèn)題解決的速度。2.2.4 網(wǎng)絡(luò)規(guī)劃優(yōu)化歷史記錄獲取網(wǎng)絡(luò)規(guī)劃報(bào)告，重點(diǎn)關(guān)注尋呼區(qū)域（位置區(qū)、路由區(qū)）的劃分。網(wǎng)絡(luò)規(guī)劃報(bào)告 獲取方式：如果是網(wǎng)絡(luò)開通前的優(yōu)化，則規(guī)劃報(bào)告可以從負(fù)責(zé)此項(xiàng)目的規(guī)劃經(jīng)理處獲得。 如果是開通后網(wǎng)絡(luò)的優(yōu)化，則規(guī)劃報(bào)告一般可從客戶處獲得。以上規(guī)劃報(bào)告應(yīng)包括網(wǎng)絡(luò) 所經(jīng)歷各次擴(kuò)容的規(guī)劃報(bào)告。對(duì)于開通后網(wǎng)絡(luò)，可能在本次優(yōu)化之前已經(jīng)經(jīng)歷了優(yōu)化過(guò)程。在本次優(yōu)化開始之前 應(yīng)獲得各次優(yōu)化歷史記錄，了解各次網(wǎng)絡(luò)調(diào)整過(guò)程及遺留問(wèn)題。應(yīng)重點(diǎn)關(guān)注是否存在覆 蓋空洞、系統(tǒng)過(guò)載、尋呼丟失、尋呼信道功率配比低等方面的優(yōu)化記錄。2.2.5 無(wú)線參數(shù)配置

24、和尋呼相關(guān)的參數(shù)如下，優(yōu)化前要注意收集：9CN尋呼重發(fā)次數(shù)、尋呼時(shí)間間隔；9UTRAN尋呼重發(fā)次數(shù)、尋呼時(shí)間間隔；9DRX尋呼周期系數(shù)k（DRX尋呼周期 = 2k）；9一個(gè)PICH幀包含的尋呼指示數(shù)目NP；9PICH、PCH信道功率配比；9CN是否使用全局尋呼；9CN尋呼使用的UE ID（是IMSI還是TMSI、PTMSI）2.3 確定優(yōu)化目標(biāo)“位置區(qū)尋呼成功率”和“路由區(qū)尋呼成功率”這兩個(gè)KPI指標(biāo)要達(dá)到優(yōu)化要求， 建議尋呼成功率達(dá)到86%以上【3】。2.4 尋呼問(wèn)題定位2.4.1 確定基本定位方向?qū)ず魡?wèn)題優(yōu)化目的是保證尋呼的KPI指標(biāo)，UE能否成功回尋呼響應(yīng)直接關(guān)系到尋呼 的KPI指標(biāo)。從

25、這個(gè)角度上看，尋呼問(wèn)題大體上可以分為三個(gè)方向：9尋呼消息根本沒有在空口下發(fā)。如果尋呼消息根本沒有在空口下發(fā)，最大的可 能是尋呼丟失，尋呼丟失是尋呼過(guò)程中最常見的問(wèn)題，也是本文分析的重點(diǎn)。 尋呼丟失的具體分析見2.4.2和2.4.3兩部分。當(dāng)然尋呼沒有發(fā)出也有可能是IUB 口傳輸故障或其它設(shè)備故障，這個(gè)問(wèn)題查看告警就能知道，這里不作贅述。9尋呼消息下發(fā)了，UE沒有收到或者是收到錯(cuò)誤的尋呼消息。按照用戶投訴的 情況具體區(qū)分，如果只是UE作被叫有問(wèn)題（語(yǔ)音提示“用戶不在服務(wù)區(qū)”）， 可能是PICH和PCH的功率配比過(guò)低或手機(jī)性能有問(wèn)題；如果UE主叫被叫都有 問(wèn)題，可能該區(qū)域存在信號(hào)覆蓋盲區(qū)。9UE收

26、到尋呼后回尋呼響應(yīng)失敗。如圖 1 所示，這個(gè)問(wèn)題屬于接入失敗的問(wèn)題， 解決方法參考WCDMA RNP 接入過(guò)程問(wèn)題分析指導(dǎo)書。在尋呼問(wèn)題定位過(guò)程中，可以通過(guò)分析尋呼話統(tǒng)、告警和用戶投訴來(lái)確定是哪種情 況。尋呼丟失一般發(fā)生在話務(wù)量高的時(shí)間段，查看CN的話統(tǒng)“位置區(qū)尋呼成功率”和 “路由區(qū)尋呼成功率”，如果這兩個(gè)指標(biāo)總是在話務(wù)量高的時(shí)間段表現(xiàn)得比較低（低于86%），用戶投訴也是集中在這一時(shí)間段，則說(shuō)明尋呼丟失較嚴(yán)重，需要重點(diǎn)分析尋呼 丟失的情況。同時(shí)查看CN是否有RNC過(guò)載告警、RNC是否有流控告警，如果有這些告 警存在說(shuō)明尋呼丟失的可能性很大。如果這兩個(gè)指標(biāo)低的事件在時(shí)間上近似均勻分布，用戶投訴

27、具有地域性，就要檢查 除“尋呼丟失”外的原因了：尋呼信道配比、信號(hào)覆蓋、手機(jī)性能等。進(jìn)一步分析尋呼問(wèn)題需要到現(xiàn)場(chǎng)進(jìn)行撥測(cè)分析，時(shí)間選擇在話務(wù)量高的時(shí)間段，地 點(diǎn)選擇用戶投訴集中的區(qū)域，撥測(cè)過(guò)程中可以在CN和RNC的維護(hù)臺(tái)上跟蹤尋呼消息的 下發(fā)和UE回尋呼響應(yīng)的過(guò)程。2.4.2 尋呼丟失直接原因?qū)ず粼谝韵虑闆r下會(huì)丟失：1、RNC系統(tǒng)處于尋呼流控狀態(tài)。因?yàn)閷ず粝l(fā)送頻率高，RNC對(duì)尋呼進(jìn)行 了流控，當(dāng)RNC檢查到CPU占有率或者消息隊(duì)列占有率達(dá)到預(yù)先設(shè)置的門 限時(shí)就會(huì)觸發(fā)尋呼流控，在尋呼流控狀態(tài)下尋呼消息無(wú)條件丟棄。2、PCH容量限制。以PCH目前的編碼方式，一個(gè)TTI只能傳輸240bits，如

28、果使 用IMSI尋呼，同一尋呼時(shí)刻只能尋呼3個(gè)UE；如果使用TMSI和PTMSI尋呼， 同一尋呼時(shí)刻只能尋呼5個(gè)UE【2】。如果在同一尋呼時(shí)刻尋呼UE的個(gè)數(shù) 超過(guò)系統(tǒng)的處理能力，就會(huì)造成尋呼丟失。3、其它原因：如IUB口傳輸故障和設(shè)備故障等，這類故障發(fā)生幾率小，可以 從告警臺(tái)看出。2.4.3 尋呼丟失原因深入分析導(dǎo)致尋呼丟失的直接原因時(shí)系統(tǒng)過(guò)載、尋呼信道過(guò)載等，進(jìn)一步地深入分析其原因 是CN和RNC使用了不適當(dāng)?shù)膶ず舨呗裕唧w分析見如下鏈接：9尋呼區(qū)域規(guī)劃過(guò)大9CN尋呼重發(fā)次數(shù)和時(shí)間間隔設(shè)置不合理9UTRAN尋呼重發(fā)次數(shù)和時(shí)間間隔設(shè)置不合理9CN使用了全網(wǎng)尋呼9DRX尋呼周期系統(tǒng)設(shè)置不合理9N

29、P值設(shè)置不合理9CN使用的UE標(biāo)識(shí)不合理2.4.4 其它原因分析9尋呼類信道功率配比過(guò)低9存在覆蓋盲區(qū)9手機(jī)性能問(wèn)題2.5 尋呼問(wèn)題優(yōu)化尋呼問(wèn)題優(yōu)化方法針對(duì)各個(gè)專題在第3節(jié)有詳細(xì)描述。2.6 優(yōu)化驗(yàn)證在對(duì)網(wǎng)絡(luò)實(shí)施了優(yōu)化調(diào)整后，需要驗(yàn)證優(yōu)化的結(jié)果。常用的驗(yàn)證方式有：運(yùn)行并查 看尋呼相關(guān)話統(tǒng)、查看是否有尋呼告警、收集用戶投訴信息、實(shí)地作手機(jī)被叫撥測(cè)等。9話統(tǒng)：主要查看“位置區(qū)尋呼成功率”和“路由區(qū)尋呼成功率”是否達(dá)到事先 確定的優(yōu)化目標(biāo)86%；9告警：查看CN是否有“RNC過(guò)載”告警，RNC是否有流控告警；9用戶投訴：在一段時(shí)間內(nèi)是否有用戶被叫投訴；9撥測(cè)：選擇話務(wù)高峰期和用戶投訴地測(cè)試手機(jī)被叫成

30、功率，撥測(cè)不需要接通， 電話只需要聽回鈴音或提示音即可。3 尋呼典型問(wèn)題分析3.1 尋呼區(qū)域規(guī)劃過(guò)大3.1.1 問(wèn)題分析CN通常在一個(gè)尋呼區(qū)域（位置區(qū)或者路由區(qū)）對(duì)目標(biāo)UE進(jìn)行尋呼，這種尋呼又稱 作本局尋呼。對(duì)CS域業(yè)務(wù)來(lái)說(shuō)，CN使用位置區(qū)來(lái)識(shí)別和尋呼UE。協(xié)議中，位置區(qū)被定義為移動(dòng)終端在不更新VLR的情況下可以自由移動(dòng)的區(qū)域。一個(gè)位置區(qū)可以涵蓋一個(gè)或 幾個(gè)小區(qū)。對(duì)PS域業(yè)務(wù)來(lái)說(shuō)，CN使用routing area來(lái)識(shí)別和尋呼UE。RA定義為在特定操 作模式下，移動(dòng)終端不需要更新SGSN的情況下可以自由移動(dòng)的區(qū)域。一個(gè)RA可以包含 一個(gè)或幾個(gè)小區(qū)。路由區(qū)和位置區(qū)的關(guān)系采用了GSM中定義的關(guān)系，即

31、：路由區(qū)可以 和位置區(qū)的大小相等，或者只是某個(gè)位置區(qū)的子集。如果尋呼區(qū)域規(guī)劃過(guò)大，網(wǎng)絡(luò)尋呼移動(dòng)臺(tái)的同一尋呼消息會(huì)在許多小區(qū)中發(fā)送，會(huì) 導(dǎo)致尋呼信道負(fù)荷過(guò)重，同時(shí)增加Iub接口上的信令流量。如果小區(qū)的尋呼信道在一段 時(shí)間內(nèi)負(fù)荷過(guò)重，會(huì)導(dǎo)致尋呼該小區(qū)UE的尋呼消息被丟掉，造成在服務(wù)區(qū)內(nèi)的開機(jī)用 戶不能被尋呼到（用戶不在服務(wù)區(qū)）問(wèn)題。反之，如果尋呼區(qū)域規(guī)劃過(guò)小，那么會(huì)造成用戶在移動(dòng)過(guò)程進(jìn)行頻繁的位置更新， 從而增加系統(tǒng)的信令流量。對(duì)于建網(wǎng)初期，PS業(yè)務(wù)尋呼需求不大，此時(shí)RA不需要刻意 劃分的過(guò)小，可按照n1來(lái)規(guī)劃。隨著網(wǎng)絡(luò)的不斷演進(jìn)，PS業(yè)務(wù)的需求不斷增多，這 時(shí)候可適當(dāng)減小RA的大小。當(dāng)然，RA過(guò)

32、小也會(huì)導(dǎo)致用戶在移動(dòng)過(guò)程中尋呼區(qū)域更新的 事件增多而導(dǎo)致網(wǎng)絡(luò)側(cè)信令開銷變大，同時(shí)也需要考慮到頻繁的位置更新會(huì)影響手機(jī)的 待機(jī)時(shí)間。尋呼區(qū)域的最大值由尋呼信道容量決定。尋呼區(qū)域容量的估算方法見【2】，引用【2】典型環(huán)境下的尋呼混合容量如表5 ：表5CN ID使用IMSI時(shí)尋呼區(qū)域計(jì)算結(jié)果表Erlang P eHrDRXCyncleLengthInN RAMmixRALA131.0.133133231.0.95190331.0.74222431.0.61244531.0.51255631.0.44264731.0.39273831.0.35280931.0.322881031.0.29290表中各個(gè)字段的含義：n是位置區(qū)大小和路由區(qū)大小的比例，LA=nRA; Mmix是PCH每個(gè)TTI能夠?qū)ず鬠E的個(gè)數(shù)； H 表示在一個(gè)DRX cycle length周期內(nèi)的一條特定尋呼塊可支持的話務(wù)量；Erlang PerDRX