【正文】 由于RNC側(cè)網(wǎng)絡(luò)模式配置錯(cuò)誤導(dǎo)致多普達(dá)手機(jī)無法進(jìn)行CS業(yè)務(wù)的問題【現(xiàn)象描述】某局某RNC下多普達(dá)S700終端無法進(jìn)行CS業(yè)務(wù)，而PS業(yè)務(wù)可以正常進(jìn)行；在另一RNC下業(yè)務(wù)均可正常進(jìn)行。打開RANAP_DIRECT_TRANSFER消息瀏覽器（如圖），消息內(nèi)容中有一條locationupdatingreject位置更新拒絕。影響異系統(tǒng)小區(qū)重選的參數(shù)主要有：QHYST1S,TRESELECTIONS, SSEARCHRAT；查看現(xiàn)網(wǎng)參數(shù)配置分別為：0，0，21，QRXLEVMIN＝－103。日常優(yōu)化過程中需要周期性的進(jìn)行外部鄰區(qū)參數(shù)的檢查。 ，鄰區(qū)配置原則發(fā)生了改變，二層鄰區(qū)間異頻時(shí)擾碼也不能相同的原則使規(guī)劃更加嚴(yán)格，更有效的保障網(wǎng)絡(luò)質(zhì)量。常見鄰區(qū)無法配置情況為鄰區(qū)的鄰區(qū)同頻同下行同步碼。 ，鄰區(qū)配置原則發(fā)生變化。首先檢查NodeB 的H信道配置一切正常，基本確認(rèn)問題出在RNC與NodeB對接上。 測試設(shè)備在其他站點(diǎn)一切正常，排除終端原因。在第一個(gè)地方設(shè)置之后，第二個(gè)地方的設(shè)置就不起作用了，僅在第一個(gè)地方?jīng)]有設(shè)置的時(shí)候在第二個(gè)地方設(shè)置才起作用。從5731上換下的USIM卡換到8130上進(jìn)行撥號設(shè)置，同樣是128 Kbps左右的數(shù)據(jù)下載速率。【建議與總結(jié)】由于TD網(wǎng)絡(luò)目前尚處與商用實(shí)驗(yàn)網(wǎng)階段，各個(gè)環(huán)節(jié)都有可能出現(xiàn)問題，需要我們細(xì)心發(fā)現(xiàn)問題，并且問題的解決要跟蹤最終結(jié)果，找到根本原因，確認(rèn)問題徹底解決。簽約速率較低。核心網(wǎng)問題。凱明手機(jī)最大下載速率為512k。從信令流程上看，PS業(yè)務(wù)建立后網(wǎng)絡(luò)下發(fā)1G、2A、4B測試控制，不下發(fā)3A，從而導(dǎo)致無法對2G系統(tǒng)的遷移。該方案可以暫時(shí)規(guī)避切換功能失敗，但犧牲了測量的準(zhǔn)確性。 終端能力不足導(dǎo)致異系統(tǒng)切換失敗【現(xiàn)象描述】在進(jìn)行基于23G基于覆蓋切換測試時(shí)發(fā)現(xiàn)網(wǎng)絡(luò)下發(fā)3A測量控制后，終端不上發(fā)3A測量報(bào)告，導(dǎo)致無法切換【原因分析】 參數(shù)配置不合理。 再查詢GSM無線側(cè)后臺數(shù)據(jù)：TD鄰區(qū)，測量門限和判決門限，都正確。的Qsearch_I修改為8，即2G服務(wù)小區(qū)的信號強(qiáng)度高于90dBm時(shí)，終端將啟動對TD鄰區(qū)的測量，并且TDD_OffSet修改為7，表明TD信號大于84dBm時(shí)，重選到TD網(wǎng)絡(luò)上。IA2142C是否添加了TD的測量頻點(diǎn)1007100810091010101110120，經(jīng)查看已經(jīng)正確添加；查看GSM小區(qū)蘋果城_C查看G網(wǎng)小區(qū)B和E的小區(qū)基礎(chǔ)數(shù)據(jù)，發(fā)現(xiàn)這兩個(gè)小區(qū)的BCCH取值均大于975，為擴(kuò)展頻點(diǎn)，現(xiàn)懷疑和頻點(diǎn)的取值有關(guān)系，故將這兩個(gè)小區(qū)的頻點(diǎn)進(jìn)行修改，但是問題依然存在。所有2/3G互操作參數(shù)配置完成以后發(fā)現(xiàn)：UE占用TD小區(qū)A時(shí)，在測試手機(jī)(大唐8130：軟件版本06A)的小區(qū)信息中可以看到G網(wǎng)鄰區(qū)B、C、D、E的信息，也可實(shí)現(xiàn)T網(wǎng)至G網(wǎng)小區(qū)B的重選，語音切換以及PS域切換（TDGPRS）等業(yè)務(wù)均正常；當(dāng)UE占用GSM小區(qū)B時(shí)，測試手機(jī)的小區(qū)信息中只有G網(wǎng)鄰區(qū)的信息，并沒有TD鄰區(qū)A的小區(qū)信息，同樣也無法實(shí)現(xiàn)G網(wǎng)至T網(wǎng)的重選。再通過ADD IPRT命令配置一條DRNC的備用路由，下一跳為源RNC對應(yīng)的CE IP?！窘ㄗh與總結(jié)】切換類問題可根據(jù)TRACE或路測數(shù)據(jù)等，先確定問題原因，及時(shí)找到問題源，結(jié)合MML等逐步查找定位?！締栴}分析】切換不成功多由如下幾類原因?qū)е拢?切換開關(guān)設(shè)置有誤； RNC涉及切換的參數(shù)配置不當(dāng)； 核心網(wǎng)參數(shù)配置不當(dāng)或不匹配； 終端原因?qū)е?；【解決方法】Step1：1）從現(xiàn)場提供的Trace信令分析，返回失敗消息為：RANAP_RELOCATION_CANCEL，其中失敗的原因?yàn)椋簍relocprepexpiry。因此網(wǎng)絡(luò)可以通過重發(fā)測量控制的時(shí)間間隔，來避免頻繁向同一個(gè)小區(qū)發(fā)起切換。即如果UE上報(bào)某個(gè)小區(qū)的信號質(zhì)量符合切換要求，此時(shí)網(wǎng)絡(luò)會發(fā)起向該小區(qū)切換的流程。RNC間接力切換功能支持情況需要進(jìn)一步驗(yàn)證。改為接力切換后，切換失敗原因統(tǒng)計(jì)（統(tǒng)計(jì)時(shí)間為1天）發(fā)現(xiàn)，物理信道失敗的次數(shù)大大減少：RRC接入過程中，同樣要進(jìn)行上行同步，為什么話統(tǒng)指標(biāo)中RRC建立成功率不受影響？這是因?yàn)镽NC側(cè)統(tǒng)計(jì)RRC嘗試次數(shù)是以接收到RRC CON REQ的次數(shù)計(jì)算的，如果沒有同步上，則不會計(jì)為一次嘗試?！拘Ч麑Ρ取縍SCP覆蓋圖對比調(diào)整前調(diào)整后C/I覆蓋圖對比調(diào)整前調(diào)整后BLER覆蓋圖對比調(diào)整前調(diào)整后可以看到的，切換懲罰時(shí)間調(diào)整后，UE能及時(shí)的切換到信號質(zhì)量最好的小區(qū)，保證了業(yè)務(wù)的質(zhì)量?！締栴}分析】在信號復(fù)雜的區(qū)域，幾個(gè)小區(qū)的信號強(qiáng)度差不多并交替變強(qiáng)，這時(shí)會發(fā)生乒乓切換問題。查詢了17161向小區(qū)17162切換的同頻、異頻切換參數(shù)設(shè)置，H1g、17161的CIO為0dB。具體數(shù)據(jù)如下表：日期對象名稱RNC 內(nèi)小區(qū)間同頻異頻硬切換出成功次數(shù)RNC 內(nèi)小區(qū)間同頻異頻硬切換出請求次數(shù)RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)RNC 內(nèi)小區(qū)間同頻異頻硬切換出成功率11/3/2009171611716229722%12/3/200917161171620330%13/03/2009171611716218713%14/03/2009171611716218713%【問題分析】分析其切換出失敗的細(xì)分類，觀察到由于物理信道失敗造成的切換出失敗占總失敗次數(shù)的大多數(shù)，如下表：日期對象名稱RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)UE無響應(yīng)RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)配置不同步RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)配置不完整RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)配置不支持RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)無效配置RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)物理信道失敗RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)小區(qū)更新RNC 內(nèi)小區(qū)間同頻異頻硬切換出失敗次數(shù)協(xié)議錯(cuò)誤11/3/2009171611716273100030012/3/2009171611716232000010013/03/2009171611716272000050014/03/20091716117162720000500物理信道失敗，通常發(fā)生于UE上報(bào)測量報(bào)告，RNC成功判決并下發(fā)物理信道重配置后，無法在切換目標(biāo)小區(qū)接收到UE的物理信道重配置完成消息。若沒有配置該種輪詢機(jī)制的話，可以不使用該定時(shí)器。 RLC參數(shù)調(diào)整參數(shù) 參數(shù)說明 修改前 修改后TIMERRST 該定時(shí)器屬于發(fā)送端，當(dāng)發(fā)送了 RESET PDU 后啟動該定時(shí)器，收到確認(rèn)后停止該定時(shí)器。提高SRB的信號接收質(zhì)量。造成我們的CELL UPDATED的成功率非常的低。可以提高UPPTS的期望接受功率或進(jìn)行UP偏移來解決。干擾導(dǎo)致。【解決方法】針對RRC接通率比較低的TOP小區(qū)，11號針對性的修改下面參數(shù)，來提高RRC接通率。RRC建立失敗的可能原因：1． RNC資源分配失敗，或者建立L2實(shí)例失敗，或者IUB接口RL鏈路失敗按照目前的用戶量和話務(wù)量，如果出現(xiàn)了前面幾種失敗原因， 一般都是RNC或者NodeB內(nèi)部出現(xiàn)了問題，需要檢查RNC和NodeB的狀態(tài)或者小區(qū)狀態(tài)?！締栴}分析】RRC建立是建立業(yè)務(wù)的前提，如果RRC建立的成功率低，業(yè)務(wù)建立成功率低的可能性也很大。RRC建立主要分為四個(gè)部分：178。2． UE收不到RRC CONNECTION SETUPRRC CONNECTION SETUP消息是在FACH上發(fā)給UE的。MML命令參數(shù)名稱修改前修改后修改原因修改范圍MOD CELLNBMOLPCULINTERFERERSV33提高上行干擾余量，間接提高SRB/RB建立時(shí)的上行期望接收功率，針對RRC接通率低的小區(qū)在RRC接通率低的top小區(qū)中修改（16772，16401，43482，42532，45681，16193，42133，17512，19061，17501）MINDLINITPWR250200提高下行初始發(fā)射功率下限【效果對比】為了驗(yàn)證修改之后，這些小區(qū)的RRC接通率性能變化情況，特跟蹤這幾天TOP小區(qū)的CS RRC和PS RRC接通率的變化趨勢，每日把這些TOP小區(qū)的RRC接通率次數(shù)和成功次數(shù)進(jìn)行累計(jì)，作為今天的RRC接通率，為了提高數(shù)據(jù)的可靠性，在作累計(jì)時(shí)，拋去當(dāng)日存在告警信息的小區(qū)。參數(shù)設(shè)置問題。檢查后臺參數(shù)發(fā)現(xiàn)上行干擾余量ULINTERFERERSVP配置為3，指導(dǎo)書中參數(shù)應(yīng)設(shè)置為3，將其改為3后，復(fù)測發(fā)現(xiàn)問題基本解決。查詢了其他廠家的此參數(shù)發(fā)現(xiàn)UE側(cè)： T313=1 N313=20 N315=4NODEB側(cè)：NINSYNCIND=1, NOUTSYNCIND=20, TRLFAILURE=50這樣大唐的配置為 UE側(cè)： NODEB側(cè)：這就是CELL UPDATE成功率高的原因。 修改RL failure定時(shí)器T313是連接模式下UE檢測無線鏈路失敗的定時(shí)器，當(dāng)UE從L1檢測到連續(xù)N313個(gè)失步指示后啟動T313定時(shí)器。D400 D1000NODISCARDMAXDAT 該參數(shù)給出了觸發(fā)某個(gè)重置過程的門限值。 D250 D200POLLPDU 該參數(shù)用于基于PDU的輪詢機(jī)制，其意義為發(fā)出POLLPDU個(gè)PDU以后發(fā)出一個(gè)輪詢指示。這表明在這時(shí)刻，切換目標(biāo)小區(qū)的信號質(zhì)量雖然滿足了切換判決，但其信號質(zhì)量并不好。由此，可以看到，由于小區(qū)17162的CIO設(shè)置過高，造成17161向比自己弱的17162切換，導(dǎo)致最后的切換失敗。在路測中就會遇到此類現(xiàn)象。 UPPTS時(shí)隙干擾影響切換成功率問題解決【問題描述】深圳TD網(wǎng)絡(luò)龍華區(qū)域中，原來普遍使用硬切換，沒有打開接力切換。因此在話統(tǒng)中沒有看出對RRC成功率的影響。 調(diào)整切換失敗時(shí)重發(fā)測量控制時(shí)間降低切換失敗率【問題描述】在跟蹤一些切換失敗率高的小區(qū)的Trace中，經(jīng)常看到同一個(gè)UE不停的往一個(gè)小區(qū)切換，但每次切換都失敗。當(dāng)切換失敗，網(wǎng)絡(luò)間隔一段時(shí)間后，會再次嘗試往該小區(qū)切換，直到達(dá)到一定的重試次數(shù)為止。重發(fā)測量控制的時(shí)間間隔和切換失敗重試周期定時(shí)器是同一個(gè)定時(shí)器。2）trelocprepexpiry即為relocation preparation expiry,RANAP_RELOCATION_CANCEL消息由RNC發(fā)給CN，可推斷為原因2）：RNC涉及切換的參數(shù)配置不當(dāng)，并初步推斷為相關(guān)的定時(shí)器配置值較小導(dǎo)致。 由于IPPATH及IPRT未配置導(dǎo)致RNC間PS切換無法進(jìn)行的現(xiàn)象【現(xiàn)象描述】在RNC間測試業(yè)務(wù)切換的過程中發(fā)現(xiàn)，CS業(yè)務(wù)正常而PS業(yè)務(wù)遷移失敗。相應(yīng)地，在目標(biāo)RNC側(cè)應(yīng)對相鄰RNC增加路由（IPPATH、IPRT）。UE占用GSM小區(qū)E時(shí)現(xiàn)象和占用B小區(qū)時(shí)現(xiàn)象一致。利用測試軟件查看層三信令發(fā)現(xiàn)，當(dāng)TD小區(qū)與G網(wǎng)小區(qū)重選正常時(shí)，TD小區(qū)重選至G網(wǎng)小區(qū)后，系統(tǒng)會下發(fā)系統(tǒng)消息SI2的QSearch_I（該參數(shù)的含義是當(dāng)2G小區(qū)的RSSI在達(dá)到一定門限時(shí)開始啟動對TD小區(qū)的測量?！窘ㄗh與總結(jié)】由于涉及到GSM小區(qū)的重選參數(shù)，在規(guī)劃2g重選小區(qū)時(shí)，應(yīng)仔細(xì)檢查并確保2g小區(qū)添加正確的頻點(diǎn)和參數(shù)的正確設(shè)置，并例行梳理2g的相關(guān)參數(shù)。因?yàn)闊o線側(cè)數(shù)據(jù)無誤，且CS業(yè)務(wù)互操作正常，初步定位核心網(wǎng)側(cè)PS業(yè)務(wù)的相關(guān)參數(shù)配置問題。 終端問題?！窘ㄗh與總結(jié)】由于TD網(wǎng)絡(luò)目前尚處與商用實(shí)驗(yàn)網(wǎng)階段，各個(gè)環(huán)節(jié)都有可能出現(xiàn)問題，需要我們細(xì)心發(fā)現(xiàn)問題，并且問題的解決要跟蹤最終結(jié)果，找到根本原因，確認(rèn)問題徹底解決。檢查異系統(tǒng)切換支持的最大PS域帶寬參數(shù)設(shè)置為128k，而測試時(shí)申請的業(yè)務(wù)為2M，相關(guān)參數(shù)如下： SET HOCOMM中TSNUMMIN及PSBANDMAX。網(wǎng)絡(luò)時(shí)隙配比是否正確。在2M測試中，跟蹤信令，發(fā)現(xiàn)SGSN下發(fā)給RNC的RAB終端申請速率不足。 大唐測試手機(jī)HSDPA測試速率過低的處理案例【現(xiàn)象描述】在**項(xiàng)目單站驗(yàn)證過程中間，使用測試手機(jī)8130和數(shù)據(jù)卡進(jìn)行HSDPA業(yè)務(wù)的速率測試，數(shù)據(jù)卡可以達(dá)到1Mbps的峰值速率，而大唐測試手機(jī)8130只能申請到128Kbps的速率?？梢远ㄎ凰俾蔬^低與手機(jī)有一定關(guān)系，跟蹤IMSI通過Iu口消息發(fā)現(xiàn)CN給RNC的RAB指配消息中指配的上下行速率為：64/128。 業(yè)務(wù)建立失敗【現(xiàn)象描述】基站開通后，進(jìn)行功能驗(yàn)證，語音與PS384業(yè)務(wù)正常，但視頻無法建立，HSDPA可以建立撥號連接，但無流量。 首先分析視頻測試文件，發(fā)現(xiàn)在終端建立業(yè)務(wù)前（connect），一切正常，在被叫測量報(bào)告下發(fā)1秒后RNC下發(fā)DISCONNECT，應(yīng)該是業(yè)務(wù)信道建立異常，針對業(yè)務(wù)信道核查參數(shù)，發(fā)現(xiàn)關(guān)于初始發(fā)射功率部分過低導(dǎo)致接續(xù)失?。ǔ跏糞IR設(shè)置過低，導(dǎo)致初始發(fā)射功率過低，無法進(jìn)行業(yè)務(wù)信道的正常建立），SIR原為2，更改為實(shí)際設(shè)置202，測試正常。 ADD AAL2PATH:ANI=1077, PATHID=3, PT=HSDPA_RT, CARRYT=IMA, CARRYF=0, CARRYSN=18, CARRYIMAGRPN=0, ADDTORSCGRP=NO, CARRYVPI=1, CARRYVCI=56, TXTRFX=152, RXTRFX=152, OWNERSHIP=LOCAL, FWDHORSVBW=0,