【文章內(nèi)容簡介】 數(shù)據(jù)進(jìn)行分析，如果指標(biāo)滿足，則結(jié)束。如果還存在問題，則需要繼續(xù)進(jìn)行，直到指標(biāo)滿足要求。對問題小區(qū)進(jìn)行分析的方法和流程參見小區(qū)級數(shù)據(jù)分析流程。小區(qū)級數(shù)據(jù)分析流程：圖 25小區(qū)級話統(tǒng)數(shù)據(jù)分析流程首先需要檢查是否存在不滿足指標(biāo)要求的小區(qū)，如果不存在則結(jié)束分析。如果存在，則需要對細(xì)化的原因值進(jìn)行分析，找到造成指標(biāo)惡化的主要原因，然后給出合適的解決方案。方案實施后需要繼續(xù)觀察分析新的話統(tǒng)數(shù)據(jù)，直到指標(biāo)滿足要求。 尋呼問題分析CN尋呼UE時，會向RNC發(fā)送PAGING消息。RNC收到消息后，根據(jù)UE當(dāng)前狀態(tài)，向UE發(fā)送PAGING TYPE1消息或者PAGING TYPE2消息。如果被尋呼的UE當(dāng)前所處狀態(tài)為IDLE、CELL_PCH或者URA_PCH，RNC將向?qū)ず魠^(qū)域內(nèi)的小區(qū)發(fā)送PAGING TYPE1消息。PAGING TYPE1消息在PCCH（Paging Control Channel）信道上發(fā)送。如果被尋呼UE當(dāng)前所處狀態(tài)為CELL_FACH或者CELL_DCH，RNC將向UE發(fā)送PAGING TYPE2消息。PAGING TYPE2消息在DCCH（Dedicated Control Channel）信道上發(fā)送。另外，UTRAN（UMTS Terrestrial Radio Access Network）可以對處于IDLE、CELL_PCH或者URA_PCH狀態(tài)的UE發(fā)送PAGING TYPE1消息，從而觸發(fā)UE修改系統(tǒng)信息；UTRAN也可以對處于CELL_PCH狀態(tài)或者URA_PCH狀態(tài)的UE發(fā)送PAGING TYPE1消息使UE產(chǎn)生狀態(tài)遷移支持?jǐn)?shù)傳。處于IDLE狀態(tài)的UE在收到PAGING TYPE1消息后，將向RNC發(fā)送RRC CONNECTION REQUEST消息請求建立RRC（Radio Resource Control）連接；處于CELL_PCH或URA_PCH狀態(tài)的UE在收到PAGING TYPE1消息后，將向RNC發(fā)送CELL UPDATE消息，小區(qū)更新的原因為“paging response”。分析尋呼性能通常從以下指標(biāo)入手：IDLE狀態(tài)UE尋呼丟失如果被尋呼的UE當(dāng)前所處狀態(tài)為IDLE，RNC將向?qū)ず魠^(qū)域內(nèi)的小區(qū)發(fā)送PAGING TYPE1消息。因此，該指標(biāo)是基于RNC的統(tǒng)計。PCH狀態(tài)UE尋呼丟失如果被尋呼的UE當(dāng)前所處狀態(tài)為CELL_PCH或者URA_PCH，RNC將向?qū)ず魠^(qū)域內(nèi)的小區(qū)發(fā)送PAGING TYPE1消息，用來使UE產(chǎn)生狀態(tài)遷移支持?jǐn)?shù)傳。因此，該指標(biāo)是基于RNC的統(tǒng)計。PCH信道擁塞當(dāng)RNC收到來自CN的尋呼消息時，如果當(dāng)前的尋呼流量超過PCH的最大能力，則會發(fā)生PCH擁塞，導(dǎo)致尋呼消息被丟棄。如出現(xiàn)“小區(qū)由于PCH信道擁塞導(dǎo)致的尋呼丟失”，說明該小區(qū)的尋呼量已到達(dá)容量極限，需檢查尋呼信道配置的相關(guān)參數(shù)。 RRC建立成功率目前網(wǎng)絡(luò)接通率主要瓶頸在于RRC連接建立成功率。本節(jié)對造成RRC建立成功率低的各種可能原因進(jìn)行分析，介紹各種問題在話統(tǒng)指標(biāo)上的表現(xiàn)以及對應(yīng)的解決方法。在話統(tǒng)中，導(dǎo)致RRC連接建立失敗的主要原因包括以下幾類：指標(biāo)ID指標(biāo)含義280RRC連接失敗次數(shù)282原因為擁塞的RRC連接失敗次數(shù)285原因為AAL2建立失敗的RRC連接失敗次數(shù)259原因為網(wǎng)絡(luò)擁塞拒絕的RRC連接失敗次數(shù)284原因為FP同步失敗的RRC連接失敗次數(shù)325原因為無應(yīng)答的RRC連接失敗次數(shù)283原因為RL建立失敗的RRC連接失敗次數(shù)36小區(qū)中RRC建立失敗的次數(shù)因Iub接口失敗而拒絕RRC連接請求，NodeB設(shè)備硬件問題，這類問題需要協(xié)調(diào)無線部門進(jìn)行定位解決。AAL2建立失敗問題很少發(fā)生，當(dāng)AAL2資源受限，或者小區(qū)出現(xiàn)故障的時候，才有可能出現(xiàn)。因網(wǎng)絡(luò)擁塞而拒絕RRC連接請求。出現(xiàn)碼資源不足，需要結(jié)合實際的話務(wù)負(fù)荷給出合理的擴(kuò)容手段。出現(xiàn)功率資源申請失敗的時候，應(yīng)該檢查準(zhǔn)入?yún)?shù)設(shè)置是否與默認(rèn)參數(shù)一致。如果參數(shù)設(shè)置合理，則需要通過話務(wù)量、等效用戶數(shù)等計數(shù)器檢查當(dāng)前網(wǎng)絡(luò)負(fù)荷。如果網(wǎng)絡(luò)負(fù)荷以及阻塞率確實達(dá)到擴(kuò)容要求，則需要啟動擴(kuò)容。UE沒有收到RNC下發(fā)的RRC CONNECTION SETUP消息。造成這種問題的原因可能是覆蓋或者小區(qū)選擇與重選參數(shù)配置不合理。目前SCCPCH功率配置的值一般是3db(相對于PCCPCH功率，單碼道)。UE發(fā)出了RRC CONNECTION SETUP COMPLETE消息，但是RNC沒有收到?？赡苁且驗闊o線環(huán)境因素造成，檢查無線環(huán)境。 RAB建立成功率目前話統(tǒng)中CSRAB指配建立失敗的原因指標(biāo)包括：無線網(wǎng)絡(luò)原因由于空口失敗導(dǎo)致RAB建立失敗。需要對RB建立失敗原因進(jìn)行分析。由于能力不足導(dǎo)致RAB建立失敗。無線資源擁塞導(dǎo)致失敗，包括功率、碼資源和帶寬等因素。傳輸網(wǎng)絡(luò)原因下表是RAB建立失敗的原因指標(biāo)ID測量指標(biāo)名稱指標(biāo)描述1598指配失敗的電路域的RAB數(shù)(小區(qū)級)1612原因為5(Tqueing Expiry)的指配失敗的電路域的RAB數(shù)(小區(qū)級)4643原因為14(Failure in the Radio Interface Procedure)的指配失敗的電路域RAB數(shù)(小區(qū)級)1607原因為19(Invalid RAB Parameters Value)的指配失敗的電路域RAB數(shù)(小區(qū)級)1608原因為20(Requested Maximum Bit Rate not Available)的指配失敗的電路域RAB數(shù)(小區(qū)級)1609原因為66(Iu Transport Connection Failed to Establish)的指配失敗的電路域RAB數(shù)(小區(qū)級)1610原因為114(No Resource Available)的指配失敗的電路域的RAB數(shù)(小區(qū)級)1611原因為115(Unspecified Failure)的指配失敗的電路域RAB數(shù)(小區(qū)級)52功率資源擁塞導(dǎo)致的CS域RAB建立失敗的個數(shù) 53上行CE擁塞導(dǎo)致的CS域RAB建立失敗的個數(shù)54下行CE擁塞導(dǎo)致的CS域RAB建立失敗的個數(shù)55碼資源擁塞導(dǎo)致的CS域RAB建立失敗的個數(shù)1192下行IUB帶寬擁塞導(dǎo)致RNC準(zhǔn)入算法拒絕從而導(dǎo)致CS域RAB指配請求建立失敗的RAB次數(shù)1193上行IUB帶寬擁塞導(dǎo)致RNC準(zhǔn)入算法拒絕從而導(dǎo)致CS域RAB指配請求建立失敗的RAB次數(shù)。目前全網(wǎng)RAB建立成功率很高，針對RAB建立成功率低的小區(qū)，后臺可以適當(dāng)調(diào)整RL的最大發(fā)射功率/ RL的最小發(fā)射功率等參數(shù)配置來改善RAB建立成功率。 RB建立成功率造成RB建立成功率低的主要原因包括下述兩大類：RB建立失敗配置不支持（configuration unsupported）主要是由于用戶的錯誤行為造成無效配置（invalid configuration）這是一個目前常見的RB建立失敗原因，可能發(fā)生的情況有：主叫3G終端進(jìn)行VP業(yè)務(wù)的被叫方駐留在GSM網(wǎng)絡(luò)，不支持VP業(yè)務(wù)。RB建立無響應(yīng)這是一個常見的RB建立失敗原因，主要是由于UE沒有收到RBSETUP消息或者RNC沒有收到UE的響應(yīng)。這樣的情形主要出現(xiàn)在弱覆蓋區(qū)。 接入問題優(yōu)化案例 RRC連接請求無響應(yīng)問題現(xiàn)象：某地區(qū)由于弱覆蓋，UE上發(fā)RRC連接請求后，下行C/I很差導(dǎo)致RRC建立失敗，引起未接通。圖 26弱覆蓋C/I截圖圖 27 RRC連接建立失敗信令截圖分析解決：由于弱覆蓋導(dǎo)致下行C/I很差，網(wǎng)絡(luò)側(cè)下發(fā)rrcConnectionSetup消息UE卻無法正常收到，導(dǎo)致RRC建立失敗。通過優(yōu)化加強(qiáng)覆蓋提高C/I解決問題。 RRC連接被拒絕問題現(xiàn)象：手機(jī)開機(jī)后注冊失敗，或者手機(jī)起呼時立刻顯示“通話結(jié)束”。從信令跟蹤上看到，RNC向NodeB發(fā)送RL建立請求后，NodeB向RNC回送RL成功應(yīng)答后，RNC發(fā)起RL鏈路刪除。分析解決：NodeB給RNC回送RL建立成功應(yīng)答以后，RNC將通過ALCAP協(xié)議發(fā)起Iub數(shù)據(jù)傳輸承載建立過程，Iub數(shù)據(jù)傳輸承載通過AAL2的綁定標(biāo)識與DCH綁定在一起，當(dāng)ALCAPIub數(shù)據(jù)傳輸承載建立過程完成后，NodeB和RNC之間進(jìn)入Iub的DCH數(shù)據(jù)傳輸過程。因此當(dāng)RNC向NodeB發(fā)送RL建立成功應(yīng)答后，RNC向NodeB發(fā)起RL刪除，說明Iub口的數(shù)據(jù)傳輸承載沒有建立起來，這樣將涉及到Iub口的ALCAP鏈路、AAL2鏈路的狀態(tài)及ATM局向地址的正確性，分別進(jìn)行排查。 RAB指派失敗問題現(xiàn)象：小區(qū)、公共信道能正常建立，打電話時，信令跟蹤上看到RAB指派后，RNC—NodeB發(fā)送“RL同步重配置準(zhǔn)備”，RNC未收到NodeB的響應(yīng)，RAB超時釋放。當(dāng)RNC發(fā)起Radio Link Reconfiguration Prepare后，沒有收到NodeB的返回信息，導(dǎo)致終止RAB指派，很有可能和CCP鏈路有關(guān)系，檢查CCP鏈路的狀態(tài)，核對RNC與NodeB的對接數(shù)據(jù)CCP端口號。 安全模式問題現(xiàn)象和分析在單用戶跟蹤中發(fā)現(xiàn)安全模式拒絕消息，如下圖所示：圖 28安全模式拒絕消息其中15:33:28（28）的RANAP_SECURITY_MODE_REJECT（上圖中紅色消息）的內(nèi)容如下圖所示：圖29RANAP_SECURITY_MODE_REJECT消息內(nèi)容從上圖中可以看到，安全模式拒絕原因為：conflict with already existing integrity protection and or ciphering information。說明最新下發(fā)的完整性保護(hù)或者加密信息與之前配置的不符。查看上一條安全模式命令中配置的加密模式信息，如下圖所示：圖30RANAP_SECURITY_MODE_COMMAND消息內(nèi)容1從上圖中可以看出，該條安全模式命令配置的加密算法是：no encryption，也就是不加密。再向前查找，發(fā)現(xiàn)了另外一條安全模式命令，如下圖所示：圖31安全模式消息這一次安全模式設(shè)置是成功了，察看該RANAP_SECURITY_MODE_COMMAND消息，如下圖所示：圖32RANAP_SECURITY_MODE_COMMAND消息內(nèi)容2可以看出這里邊給出了2個加密方式：UEA1和不加密。根據(jù)協(xié)議規(guī)定，如果給出2個加密算法供選擇，其中一個是需要加密，另外一個是不加密，則選擇需要加密的那個算法。也就是說，這里是需要加密的。對比這兩條加密模式命令，發(fā)現(xiàn)他們來自不同的CN域：之前成功的這條的CN域編號為4669，而失敗的那條來自4666。也就是說，CS域和PS域配置了不同的加密方式。而RNC先收到0所示的安全模式命令后，選擇了UEA1作為加密算法。后來又收到0所示的安全模式命令，而這條安全模式命令又要求不加密，導(dǎo)致RNC拒絕了該安全模式命令。解決方法將CS和PS的加密方式設(shè)為相同，問題解決。 切換專題優(yōu)化 DT/CQT指標(biāo)優(yōu)化流程DT和CQT是網(wǎng)絡(luò)評估、優(yōu)化最重要的兩個手段，DT/CQT KPI經(jīng)常作為網(wǎng)絡(luò)初驗的標(biāo)準(zhǔn)。通過全面的路測可以了解整體覆蓋情況，是否有越區(qū)覆蓋、弱覆蓋、覆蓋空洞、鄰區(qū)漏配等問題。下面從系統(tǒng)內(nèi)切換、系統(tǒng)間切換兩個方面來討論DT/CQT指標(biāo)的優(yōu)化流程。系統(tǒng)內(nèi)切換DT指標(biāo)優(yōu)化流程切換路測數(shù)據(jù)分析流程如下圖所示：圖 33切換路測數(shù)據(jù)分析流程輸入分析數(shù)據(jù)進(jìn)行路測，采集路測數(shù)據(jù)，并同時收集相關(guān)跟蹤的信令和RNC的MML腳本。獲取問題發(fā)生的時間和地點測試過程中會發(fā)生切換掉話或者切換失敗，記錄下切換問題發(fā)生的位置、時間等信息，并初步判斷發(fā)生切換的類型是RNC內(nèi)切換、跨RNC切換、跨CN切換，為后續(xù)的定位分析做準(zhǔn)備。是否鄰區(qū)漏配一般來講，初期優(yōu)化過程切換掉話占大多數(shù)是由于鄰區(qū)漏配導(dǎo)致的。對于鄰區(qū)漏配，通常采用如下方法進(jìn)行確認(rèn)：方法一：通過路測軟件的地圖信息和基站位置信息，一般我們可以初步判斷切換時的目標(biāo)小區(qū)，如果切換掉話前目標(biāo)小區(qū)并未出現(xiàn)在路測軟件的鄰區(qū)列表當(dāng)中，則可以初步判斷屬于鄰區(qū)漏配；方法二：觀察掉話前UE記錄的服務(wù)小區(qū)的PCCPCH RSCP信息和Scanner記錄的TOPN小區(qū)信息，如果UE記錄的服務(wù)小區(qū)PCCPCH RSCP很差，而Scanner記錄的TOPN小區(qū)中的最強(qiáng)小區(qū)場強(qiáng)很好；同時檢查Scanner記錄TOPN小區(qū)中的最強(qiáng)小區(qū)的擾碼是否出現(xiàn)在掉話前最近出現(xiàn)的測量控制的鄰區(qū)列表中，如果測量控制的鄰區(qū)列表中中沒有該擾碼，那么可以確認(rèn)是鄰區(qū)漏配。方法三：如果掉話后UE馬上進(jìn)行小區(qū)重選，而UE重選的小區(qū)擾碼和掉話時的擾碼不一致，也可以懷疑是鄰區(qū)漏配問題，可以通過測量控制進(jìn)一步進(jìn)行確認(rèn)（從掉話位置的消息開始往前找，找到最近的同頻或異頻測量控制消息，檢查該測量控制消息的鄰區(qū)列表）。鄰區(qū)漏配會導(dǎo)致掉話，鄰區(qū)冗余也會對網(wǎng)絡(luò)性能有影響，會增加UE測量的消耗，嚴(yán)重情況下使得需要加入鄰區(qū)的小區(qū)無法加入，所以在切換問題分析中也要關(guān)注鄰區(qū)冗余的問題。是否導(dǎo)頻污染通常將導(dǎo)頻污染定義為：在某一點存在過多的強(qiáng)導(dǎo)頻，但卻沒有一個足夠強(qiáng)的主導(dǎo)頻。根據(jù)這一定義，在制定導(dǎo)頻污染判別標(biāo)準(zhǔn)時，需要確認(rèn)的內(nèi)容包括：“強(qiáng)導(dǎo)頻”的定義“過多”的定義“沒有一個足夠強(qiáng)的主導(dǎo)頻”的定義“強(qiáng)導(dǎo)頻”的定義當(dāng)確定某一導(dǎo)頻是否為強(qiáng)導(dǎo)頻時，判斷標(biāo)準(zhǔn)是該導(dǎo)頻的絕對強(qiáng)度。對于導(dǎo)頻強(qiáng)度，可以通過導(dǎo)頻的RSCP來衡量，如果導(dǎo)頻的RSCP大于某一門限，判定該導(dǎo)頻為強(qiáng)導(dǎo)頻。即：“過多”的定義當(dāng)判斷某一地點是否存在過多的導(dǎo)頻時，判斷標(biāo)準(zhǔn)是導(dǎo)頻數(shù)目的多少。如果某一地點的導(dǎo)頻