外場異常事件研究-fdd lte trouble shooting

FDDLTE外場異常事件TroubleShootingWeiDong目錄

1、LTE網(wǎng)絡(luò)性能指標關(guān)注點2、接入問題分析3、切換問題分析4、掉話問題分析5、可用性分析接入性：RRC建立成功率

E-RAB建立成功率S1建立成功率可用性：小區(qū)在網(wǎng)率

資源利用率上/下行吞吐率保持性：RRC掉線率E-RAB掉線率

移動性：eNB內(nèi)/外切換成功率S1/X2切換成功率同/異頻

切換成功率LTE網(wǎng)絡(luò)問題關(guān)注點目錄

1、LTE網(wǎng)絡(luò)性能指標關(guān)注點2、接入問題分析3、切換問題分析4、掉話問題分析5、可用性分析接入流程介紹

隨機接入場景：空閑模式下初始接入

無線鏈路失步后的RRC重建

切換到新小區(qū)上行失步狀態(tài)要進行下行數(shù)傳上行失步狀態(tài)要進行上行數(shù)傳接入流程主要分為以下幾個步驟:隨機接入RRC連接建立鑒權(quán)等NAS過程E-RAB建立接入問題

接入失敗是指用戶發(fā)起業(yè)務(wù)，但無法成功建立業(yè)務(wù)的情況；ENB側(cè)問題；UE側(cè)問題；無線環(huán)境影響；核心網(wǎng)側(cè)問題。話統(tǒng)中接入成功率統(tǒng)計：CTC定義了兩個和接入成功率相關(guān)的KPI,初始接入成功率=RRC連接建立成功率×S1信令連接建立成功率×初始E-RAB建立成功率;無線連接成功率=RRC連接建立成功率×S1信令連接建立成功率×初始E-RAB建立成功率×E-RAB建立成功率CMCC和CUC定義如下，

無線接通率=RRC建立成功率×

ERAB建立成功率路測接入成功率統(tǒng)計：一般在路測中會記錄UE側(cè)和eNB側(cè)的消息跟蹤，根據(jù)信令流程可以判斷接入是否成功；路測軟件一般會自動判斷接入是否成功從而得出接入成功率、接入問題優(yōu)化思路

序號問題分析步驟分析內(nèi)容1KPI惡化分析

分析接入成功率惡化的的時間和趨勢；2故障告警排查對設(shè)備故障告警進行排查和分析，需要特別注意指標惡化時段的歷史告警；3參數(shù)核查

如果全網(wǎng)指標惡化，核查升級前后的參數(shù)變化；如果是Top站點問題，可以和指標正常站點進行參數(shù)核查；license是否受限等；4失敗原因細分分析話統(tǒng)，確認是哪個階段的問題，并給出失敗的話統(tǒng)原因分布；分析信令，定位接入流程是在哪一步失敗；5干擾排查

需要確認TOP小區(qū)是否存在互調(diào)干擾，外部干擾，模3干擾；6TOP用戶排查分析TOP小區(qū)是否由于TOP用戶引起；7TOP終端排查

分析TOP小區(qū)是否由于TOP終端引起；8其他基站升級、核心網(wǎng)升級、傳輸設(shè)備升級、重大節(jié)日活動、產(chǎn)品硬傷KPI變化分析分析KPI日變化趨勢：對最近半個月或更長時間段的接入成功率進行基于日期的趨勢分析，并結(jié)合業(yè)務(wù)量、用戶數(shù)、接入次數(shù)、網(wǎng)絡(luò)升級等進行相關(guān)分析，確認接入問題趨勢以及是否和業(yè)務(wù)量、用戶數(shù)、升級等因素相關(guān)；分析KPI時段變化趨勢：

分析24小時的的接入成功率數(shù)據(jù)，并結(jié)合業(yè)務(wù)量、用戶數(shù)、接入次數(shù)、網(wǎng)絡(luò)升級等進行相關(guān)分析，確認接入問題趨勢以及是否和業(yè)務(wù)量、用戶數(shù)、升級等因素相關(guān)；失敗原因細分：UE問題、核心網(wǎng)問題、資源不足等。BTSSiteManager——單站告警查看SiteBrowser/NetAct/AP——批量告警查看故障告警排查

重點排查問題發(fā)生時間點對應(yīng)的告警重點排查告警級別為Critical和Major的告警iPlatPopulaPiano參數(shù)核查

參數(shù)核查建議：如果是涉及網(wǎng)絡(luò)升級，核查升級前后的參數(shù)變化；如果是Top站點問題，可以和指標正常站點進行參數(shù)核查；參數(shù)核查工具：EasyDB/Piano/Popula/iPlat等EasyDBSiteManager干擾排查

模3干擾排查PCI規(guī)劃不合理，可以通過調(diào)整PCI解決；PCI規(guī)劃合理，但是覆蓋不合理，包括覆蓋方向不合理和覆蓋距離不合理，可以通過調(diào)整方位角、下傾角、功率等辦法解決；基站規(guī)劃不合理，或者被阻擋，導致部分區(qū)域無主導頻，引起MOD3干擾，可以通過增加信源或者整改基站位置、天線掛高、天線類型、功率參數(shù)優(yōu)化等辦法來突出主導頻，減小干擾。外部干擾排查FDD試驗網(wǎng)前期，CTC、CUC使用相當頻段進行組網(wǎng)，相互干擾；熱點區(qū)域聯(lián)通WCDMA使用第四頻點（10713、10688、10663、10638…）與電信2.1GLTE相互干擾；其他外部干擾DOEmil路測對比、用戶投訴話單分析，相關(guān)工具開發(fā)中TOP用戶、TOP終端排查

蘭州聯(lián)通客戶大量投訴手機駐留在LTE網(wǎng)絡(luò)時做主叫正常，做被叫無響應(yīng)，分析投訴發(fā)現(xiàn)問題手機的型號均為華為的P7；跟蹤信令流程發(fā)現(xiàn)P7在做CSFB時，中興的MSCServer會將尋呼指向3G網(wǎng)絡(luò)；P7在完成通話后回到LTE網(wǎng)絡(luò)時發(fā)起的TAU的類型為TYPE1；根據(jù)3GPP規(guī)范MME收到TYPE1的TAU時不需要向MSCSERVER發(fā)LocationUpdateRequest消息；因此中興的MSCserver的尋呼指向仍然是3G側(cè)，此時P7駐留在LTE上就收不到任何尋呼消息。此問題為中興MSCserver的產(chǎn)品缺陷，中興MSC軟件版本升級后解決此問題接入案例：華為P7手機無法做被叫

蘭州聯(lián)通的網(wǎng)絡(luò)拓撲P7手機返回LTE網(wǎng)絡(luò)后發(fā)起TAU請求，類型為TYPE1接入案例：華為P7手機無法做被叫

機型是否未接通UE發(fā)送信令TAU消息類型MME是否發(fā)送信令至SERVERSERVE接收信令情況eNB是否收到paging或指示消息

三星S3I9305否type2是接收是三星S4I9505否type2是接收是諾基亞lumia925否type2是接收是中興Q-801U否type2是接收是IPHONE5S否type2是接收是華為P78次未接通type18次未發(fā)送8次未收到8次未收到華為MATE28次未接通type18次未發(fā)送8次未收到8次未收到華為P1U920-LTE否type2是接收是在發(fā)現(xiàn)此問題現(xiàn)象之后對三星、諾基亞、蘋果、華為、中興五大品牌共計8款終端進行了被叫CSFB測試。每款終端均進行10次被叫語音測試。可以看出三星、諾基亞、中興、蘋果以及華為早期的LTE終端返回LTE網(wǎng)絡(luò)后均上報type2類型的TAU請求。而華為近期上市的終端如華為P7與MATE2則進行了修正，快回至LTE網(wǎng)絡(luò)后，上報type1類型的TAU請求。這兩款終端的被叫CSFB成功率極低，僅為20%左右。接入案例：華為P7手機無法做被叫

中興將MSCserver3升級至OMMV3.07.63.P2版本，新增SGs口狀態(tài)優(yōu)化功能。已解決華為P7等終端無法進行被叫CSFB業(yè)務(wù)的問題；升級完成后，進行華為P7被叫CSFB業(yè)務(wù)測試，P7快回至LTE網(wǎng)絡(luò)后，不再需要MME與MSCserver之間進行SGs聯(lián)合位置區(qū)更新，被叫CSFB業(yè)務(wù)驗證正常接入案例：不合格濾波器導致無法接入

諾基亞設(shè)備雜散指標（約-40dBm/MHz），不滿足工信部[2012]559號文件要求，即雜散功率小于-65dBm/MHz，對于不滿足工程隔離要求的FDD基站需要加裝濾波器；項目上配貨MOBI帶通濾波器，帶通頻段為1850-1875MHZ，安裝后2T4R基站工作正常，2T2R基站無法接入；經(jīng)過確認，配置的1850-1875MHZ帶通濾波器，上行頻段亦被阻塞，導致2T2R配置情況下，基站無法收到上行信號。接入案例：MIMO單通道室分系統(tǒng)接入問題

MIMO單通道室分系統(tǒng)：RRU兩通道分別覆蓋A、B兩個不同區(qū)域；問題現(xiàn)象：終端在RRU某一端口對應(yīng)天線下搜索不到信號。以FRGT為例，1端口覆蓋B區(qū)域,3端口覆蓋A區(qū)域，終端在B區(qū)域測試正常，終端從B區(qū)域移動到A區(qū)域后，可以正常做業(yè)務(wù)，但是在A區(qū)域UE重新Poweron后，終端搜索不到信號；接入案例：MIMO單通道室分系統(tǒng)接入問題

通過參數(shù)核查發(fā)現(xiàn)室分小區(qū)的syncSigTxMode同步信號傳輸模式配置存在問題；syncSigTxMode設(shè)置為SingleTX時，PSS和SSS只在一路天線上發(fā)射，導致另一路天線下搜索不到信號；將syncSigTxMode修改為TxDiv時，問題解決；

MIMO單通道室分系統(tǒng)，該參數(shù)應(yīng)設(shè)置為TxDiv接入案例：RRC重建問題

當前基站版本不支持RRC第三小區(qū)重建：RRCconnectionre-establishment在第三小區(qū)，

重建立請求會被拒絕，這里的第三小區(qū)是指非servingcell以及非Handovertarget

cell；RL70/RL55支持，

LTE1617feature.DAYRRC重建成功率RRC重建立成功次數(shù)RRC重建立請求次數(shù)2014/8/171.493214492014/8/242.751122622014/8/361.412263682014/8/448.451252582014/8/568.702373452014/8/681.945997312014/8/768.104126052014/8/863.58501788RRC重建成功率低產(chǎn)品硬傷接入案例：S1信令建立成功率

CTCrequiredtomonitorS1signalingconnectionsuccessrate.NopropercounterdesignedinNokiasystem.Definition:S1signalingconnectionattempttimes,triggerby"INITIALUEMESSAGE"sendfromBTStoMME.S1signalingconnectionsuccessfultimes,triggerby"INITIALCONTEXTSETUPREQUEST"or"DOWNLINKNASTRANSPORT"or"UECONTEXTRELEASECOMMAND"sendfromMMEtoBTS.Theratio:"S1signalingconnectionattempttimes"/"S1signalingconnectionsuccessfultimes"Thesuccessfultimesshouldincreaseonlyonetimealthoughthetwomessages“INITIALCONTEXTSETUPREQUEST”and“DOWNLINKNASTRANSPORT”willappeartogetherfollowingby“INITIALUEMESSAGE”.ThesuccessfultimesincreasedtwotimesinthiseventbasedonpresentcountersINITIALUEMESSAGE=1,DOWNLINKNASTRANSPORT=1,INITIALCONTEXTSETUP=1(denom=1+1)LogofMTINITIALUEMESSAGE=1,INITIALCONTEXTSETUP=1,UECONTEXTRELEASECOMMAND=1(Denom=1+1=2))UEreleasealsotrigger產(chǎn)品硬傷目錄

1、LTE網(wǎng)絡(luò)性能指標關(guān)注點2、接入問題分析3、切換問題分析4、掉話問題分析5、可用性分析LTE切換切換的過程就是終端在移動過程中與網(wǎng)絡(luò)連接交互發(fā)生變化的過程：LTE切換過程由eNB控制，eNB下發(fā)測量控制讓UE在滿足一定條件時上報測量報告觸發(fā)：NOKIA采用A3、A5事件觸發(fā)同頻、異頻切換切換：eNB下發(fā)切換命令給UE，UE收到切換命令后，中斷與源小區(qū)的交互，按命令切換到目標小區(qū)切換信令流程介紹LTE切換成功率是移動保持類的重要指標，按照涉及的網(wǎng)元關(guān)系可以分為ENB內(nèi)切換、ENB間（包括X2切換和S1切換）切換切換問題優(yōu)化思路參考接入問題優(yōu)化思路需特別注意參數(shù)核查階段：

確認切換開關(guān)狀態(tài)；確認LNADJ/LNREL等鄰區(qū)關(guān)系是否配置等；確認切換參數(shù)，如切換門限，遲滯，觸發(fā)時間等；確認是否存在PCI復(fù)用距離過近；切換案例：PCI復(fù)用距離過近影響切換PCI復(fù)用距離過近，典型的基站相對位置如下圖發(fā)現(xiàn)途徑：路測中發(fā)現(xiàn)，通常在建網(wǎng)初期或有新站入網(wǎng)時常見；KPI分析中發(fā)現(xiàn)，在詳細的切換數(shù)據(jù)中，找到切換失敗次數(shù)最多的源小區(qū)，登陸到該小區(qū)下，檢查鄰區(qū)配置，是否有同PCI；參數(shù)核查工具批量核查。切換案例：睡眠小區(qū)影響切換8月19日肥西火車站基站，周邊基站切入全部失?。桓婢瞬?，無任何告警；無參數(shù)修改記錄，參數(shù)核查無異常；重啟基站，無法恢復(fù)。DAYTimeS_eNBIDT_eNBID切換成功率切換成功測試切換成功請求次數(shù)8月18日21432111432113100.00%15158月18日21432110432113100.00%668月18日21432105432113100.00%13138月19日214321114321130.00%068月19日214321104321130.00%088月19日214321054321130.00%0168月20日21432111432113100.00%21218月20日21432110432113100.00%12128月20日21432105432113100.00%1111切換案例：睡眠小區(qū)影響切換核查基站軟件版本，發(fā)現(xiàn)該基站版本為LN6.0_ENB_1311_362_01，非P8；升級為P8版本LN6.0_ENB_1311_613_00后，問題解決；版本LN6.0_ENB_1311_617_01，也存在小區(qū)休眠問題；731_01版本，目前看來還算比較穩(wěn)定切換案例：eNB

ID沖突影響切換7月24日合肥全網(wǎng)切換指標惡化嚴重；切換失敗原因細分：集中在瑞錦工貿(mào)基站與瑞泰和園基站之間的S1切換；DAY切換成功率切換成功測試切換成功請求次數(shù)7月18日98.72%162116427月19日98.88%176217827月20日98.94%186318837月21日98.93%184518657月22日99.03%203420547月23日98.98%193219527月24日46.48%119525717月25日98.94%185818787月26日98.99%195119717月27日98.98%194519657月28日98.91%18141834切換案例：eNB

ID沖突影響切換告警核查，瑞泰和園基站反復(fù)出現(xiàn)S1告警，導致S1切換失??；協(xié)調(diào)客戶核查，發(fā)現(xiàn)同一MME下，中興新開基站使用eNB

ID與瑞泰和園基站相同；中興修改eNB

ID修改后，問題解決；切換案例：PRACH參數(shù)規(guī)劃問題導致切換失敗6.5KM7.5KM問題描述：

豐油坊1、2小區(qū)切往長豐義井2小區(qū)全失?。婚L豐莊墓2小區(qū)切往長豐義井1小區(qū)全失??；長豐涂拐3小區(qū)切往長豐義井3小區(qū)全失敗5KM切換案例：PRACH參數(shù)規(guī)劃問題導致切換失敗參數(shù)核查發(fā)現(xiàn)鄉(xiāng)村基站PRACH相關(guān)參數(shù)存在問題，鄉(xiāng)村基站PrachCs和城區(qū)基站設(shè)置一致，都為8，對應(yīng)小區(qū)覆蓋半徑CellRange為5.48km。PrachCs設(shè)置為8時，不能有效滿足農(nóng)村覆蓋場景的隨機接入。838/64/

切換案例：PRACH參數(shù)規(guī)劃問題導致切換失敗重新規(guī)劃PRACH相關(guān)參數(shù)，PrachCs設(shè)置為11，CellRange最大可支持12.2Km；以長豐油坊1、2小區(qū)切往長豐義井2小區(qū)為例：修改前之前切換全失敗，改后全成功切換案例：D2終端切換問題問題現(xiàn)象：UE由華為小區(qū)PCI-94切往諾基亞小區(qū)PCI-243,D2出現(xiàn)異常問題，E392則正常切換。此異常問題不僅僅出現(xiàn)在HW至NOKIA邊界，在HW小區(qū)及NOKIA內(nèi)部都出現(xiàn)此異常現(xiàn)象。測試終端D2測試終端E392上報A3事件重選至目標小區(qū)在目標小區(qū)重建被拒絕EAB異常釋放上報A3事件成功切換至PCI-243切換案例：D2終端切換問題測試時間2014/12/12&13&16測試時長6h23m42s5h19m24s3h59m38s總距離76.1km63.87km49.1km測試設(shè)備D2E392iphone5s切換總次數(shù)487648343重選失敗次數(shù)/重選總次數(shù)0/240/4-

異?，F(xiàn)象700case現(xiàn)象200諾基亞華為大量測試結(jié)果顯示：D2終端會出現(xiàn)異常問題現(xiàn)象（cause原因值：other），E392和iphone5s沒有出現(xiàn)異常問題現(xiàn)象。目錄

1、LTE網(wǎng)絡(luò)性能指標關(guān)注點2、接入問題分析3、切換問題分析4、掉話問題分析5、可用性分析E-RAB異常釋放定義

不同運營商對E-RAB異常釋放的定義存在差異：E-RAB異常釋放定義——CTC（1）統(tǒng)計消息為eNodeB向MME發(fā)送的“E-RABRELEASEINDICATION”消息。當相應(yīng)承載有數(shù)據(jù)傳送且釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATredirection”時統(tǒng)計。（2）統(tǒng)計消息為eNodeB向MME發(fā)送的“UECONTEXTRELEASEREQUEST”消息。當有數(shù)傳數(shù)據(jù)傳送且釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATredirection”時統(tǒng)計。E-RAB異常釋放定義——CUC1、當eNodeB向MME發(fā)送E-RABRELEASEINDICATION消息，當釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATRedirection”，“SuccessfulHandover”等原因時累加統(tǒng)計。另需根據(jù)不同QCI類型統(tǒng)計該指標；2、當eNodeB向MME發(fā)送UECONTEXTRELEASEREQUEST消息，釋放UE所有E-RAB，當判斷相應(yīng)承載有數(shù)傳且釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATRedirection”，“TimeCriticalHandover”，“HandoverCancelled”等原因時累加統(tǒng)計掉話問題優(yōu)化思路參考接入問題優(yōu)化思路特別注意

掉話問題通常會伴隨著切換失敗而來。掉線案例：上行功控開關(guān)未開影響掉線

客戶投訴鴻宇7F經(jīng)常掉線，下載速率不穩(wěn)定該室分話務(wù)量較大掉線案例：上行功控開關(guān)未開影響掉線

對鴻宇7f進行了測試，發(fā)現(xiàn)在無線環(huán)境相當良好的情況下存在大量的RRCrelease，原因都為other進一步通過BTSlog發(fā)現(xiàn)，掉線原因為大部分是由于CQIDTX上行失步導致了RRCrelease掉線案例：上行功控開關(guān)未開影響掉線檢查參數(shù)，發(fā)現(xiàn)Pucch上行功控都處于關(guān)閉狀態(tài)，鴻宇7F的UE較多，Pucch上行干擾較大導致ENB無法正確解碼UE上報CQI，導致上行失步而釋放RRC鏈路。對以下參數(shù)進行優(yōu)化，如下表所示：參數(shù)修改后，問題解決目錄

1、LTE網(wǎng)絡(luò)性能指標關(guān)注點2、接入問題分析3、切換問題分析4、掉話問題分析5、可用性分析可用性分析——小區(qū)可用率

小區(qū)可用率

小區(qū)可用率低，會影響到其他性能指標，需要日常監(jiān)控。影響小區(qū)可用率的主要因素：硬件故障，需要維護部門配合處理；人為閉鎖，需及時放開；工程基站調(diào)測建立故障基站處理檔案城市日期忙時小區(qū)可用率(%)合肥2014年7月29日2195.22%合肥2014年7月30日2196.23%合肥2014年7月31日2195.24%合肥2014年8月1日2194.98%合肥2014年8月2日2196.64%可用性分析——資源利用率

資源利用率License資源利用情況最大RRC連接數(shù)；最大激活用戶數(shù)；信道資源利用率尋呼信道；PRACH信道；PDCCH信道；PRB資源利用率上行PRB資源利用率下行PRB資源利用率

可用性分析——資源利用率

城市日期忙時PDCCH信道占用率(%)PRACH信道占用率(%)尋呼信道占用率(%)RRC連接許可用戶數(shù)使用率(%)上行PRB平均利用率(%)下行PRB平均利用率(%)合肥2014年7月29日211.81%0.40%2.82%0.03%14.52%0.29%合肥2014年7月30日211.75%0.46%3.35%0.03%14.54%0.26%合肥2014年7月31日211.80%0.36%3.44%0.03%14.67%0.29%合肥2014年8月1日211.80%0.91%5.07%0.03%14.58%0.31%合肥2014年8月2日211.79%0.62%5.63%0.03%14.58%0.27%建網(wǎng)初期，用戶少，各項資源利用率偏低；上行PRB平均利用率較下行PRB平均利用率明顯高出許多；15M系統(tǒng)帶寬配置無用戶情況下，上行PRB利用率約為14%，即約有10個RB固定被控制信道占用，這個在網(wǎng)絡(luò)初期有點浪費資源，對上行吞吐量也會有一定的影響。上行控制信道PUCCH默認開銷大，PUCCHFormat1/1a/1b/2/2a/2b.其中,Format2中用于反饋CQI的nCqirb,開站默認配置6個RB?？捎眯苑治觥舷滦型掏侣?/p>

速率影響因素——Bandwidth（帶寬），LTE主要6種帶寬（1.4、3、5、10、15、20）Uplink-Downlinkconfiguration（上下行子幀配置）(TDD)控制信道pdcch占用的symbol符號個數(shù)MIMO(手機需支持，現(xiàn)在最高2T2R)TM（傳輸模式TM2/TM3/TM7/TM8）airinterferenceload（是否設(shè)置空口加擾，50%，70%）系統(tǒng)設(shè)置可用性分析——上下行吞吐率

UECategoryMaximumnumberofDL-SCHtransportblockbitsreceivedwithinaTTIMaximumnumberofbitsofanUL-SCHtransportblocktransmittedwithinaTTICategory1102965160Category25102425456Category310204851024Category415075251024Category529955275376速率影響因素——手機芯片處理能力（解調(diào)）手機是否支持MIMO手機能力等級category手機接收靈敏度（間接）下表為3Gpp中下行UE不同能力的一些定義終端因素可用性分析——上下行吞吐率

速率影響因素——基站射頻故障(RRU)或駐波比告警、天線端口功率不平衡（antenna0與antenna1接收電平差異過大）；傳輸帶寬限制基站硬件及傳輸因素可用性分析——上下行吞吐率

速率影響因素——由于天饋工程設(shè)置或客觀山體樓體阻擋導致信號快衰，SINR下降明顯，被網(wǎng)絡(luò)側(cè)判斷為覆蓋邊緣，影響資源調(diào)度和調(diào)制方式的使用；功率參數(shù)不合理導致無法進行主覆蓋，引起SINR偏低；重疊覆蓋：部分區(qū)域存在多個信號（相差在6dB內(nèi)），同時覆蓋一個區(qū)域；過覆蓋：存在遠距離信號干擾，導致SINR較差，直接影響下行速率；室內(nèi)弱覆蓋（如地下室、車庫、無室分系統(tǒng)的高層、電梯）由于信號不穩(wěn)定，導致SINR波動大，影響用戶感知；切換問題：鄰區(qū)漏配、切換參數(shù)不合理；內(nèi)部干擾：同頻干擾、PCI模3沖突等；外部干擾：主要是直放站及干擾器；無線環(huán)境影響可用性分析——上下行吞吐率

速率影響因素——測試服務(wù)器問題，由于服務(wù)器處理能力不同，相同終端在不同服務(wù)器下載的速率不盡相同；測試本硬盤讀寫能力，由于筆記本性能不同，硬盤讀寫能力不同，會導致測試及用戶使用過程中感知的速率可能不同；手機軟件吊死或死機，可通過重啟解決；用戶行為，同一小區(qū)下存在多個用戶同時進行業(yè)務(wù)；工程施工質(zhì)量問題其他因素案例：修改nCqiRb改善上行速率

將ncqiRB由6修改為2；PrachFreqOff同步進行修改，考慮到上行業(yè)務(wù)信道PRB需要連續(xù)分配；其他參數(shù)被動修改；參數(shù)名縮寫默認值優(yōu)化值備注PUCCHbandwithforCQI

nCqiRb62

PRACHfrequ