LTE 路測和網絡問題案列分析_第1頁
LTE 路測和網絡問題案列分析_第2頁
LTE 路測和網絡問題案列分析_第3頁
LTE 路測和網絡問題案列分析_第4頁
LTE 路測和網絡問題案列分析_第5頁
已閱讀5頁,還剩21頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

LTE路測和網絡問題案列分析覆蓋問題分析覆蓋類問題涉及弱覆蓋、越區覆蓋、過覆蓋、無主導小區、上下行不平衡及導頻污染等。弱覆蓋:在LTE中一般認為RSRP<-100dBm,認為是弱覆蓋。越區覆蓋:由于基站天線掛高過高或下傾角過小引起的該小區覆蓋距離過遠,從而越區覆蓋到其他站點覆蓋的區域,并且在該區域終端接收到的信號電平較好。過覆蓋:指網絡中存在過度的覆蓋重疊,容易引起干擾和乒乓切換;無主導小區:指某一片區域內服務小區和鄰區的接收電平相差不大,不同小區之間的下行信號在小區重選門限附近的區域,并且無主導覆蓋的區域接收電平一般或者較差,且服務小區的SINR不穩定,可能發生空閑態主導小區頻繁重選、連接態頻繁切換,無主導覆蓋也可認為是弱覆蓋的一種。導頻污染:指在某一點存在過多(一般認為大于等于3個)的強導頻,但卻沒有一個足夠強的主導頻;造成覆蓋問題的原因:無線網絡規劃的準確性;實際站點與規劃站點位置偏差;實際工參與規劃工參不一致;覆蓋區建筑物增加、減少、阻擋等原因無線環境發生變化;新增站、搬遷站及無法開通站等原因無線環境發生變化;燈桿站、美化天線及業務等原因天線無法調整;處理方案:調整天線方位角、下傾角到合理位置;調整PCI、功率等參數調整;合理設置切換帶及鄰區優化;增加新站、RRU拉遠等;覆蓋問題分析對簇中每個小區分析,確定簇優化方案對簇中主要問題點分析,微調簇優化方案實施簇優化方案覆蓋問題分析---單小區覆蓋分析單小區分析確認是基礎工作,在對網絡進行測試摸底之后,首先要針對各個小區進行單小區分析和統計,了解每個小區的實際覆蓋情況,設計合理的覆蓋區域、切換帶,避免做出錯誤的判斷。分析的內容包括天線接反/鴛鴦線核查、單小區覆蓋越區核查、天線的旁瓣和背瓣覆蓋核查、無覆蓋小區核查、切換帶分析。RSRP:通過RF調整優化后RS-RSRP大于-100dbm的區域由原來的84.57%提升為99.28%,RS-RSRP提升了14.71%。優化前后RSRP/SINR對比圖:

SINR:通過RF調整優化后RS-SINR大于-3dB的區域由原來的85.17%提升為99.34%,RS-SINR提升了14.17%。DLThroughput:通過RF調整優化后下行PDCP層平均吞吐率由原來的24.39Mbps提升為46.94Mbps,提升22.55Mbps。優化前后DL/ULThroughput對比圖:

ULThroughput:通過RF調整優化后上行PDCP層平均吞吐率由原來的13.54Mbps提升為39.66Mbps,提升26.12Mbps。1.嚴格控制每小區覆蓋半徑,盡可能避免過覆蓋、越區覆蓋,合理設置切換帶;2.簇優化人員對所負責的簇中的每個站情況非常了解,便于后期問題定位;3.給項目組提供最準確的工參信息;4.減少重后期復上站次數;5.單小區優化同時可以解決過覆蓋及干擾問題;簇優化單小區分析優點

掉線問題分析掉話常見現象:UE發起重建立過程

cause為OtherFailure(UEradiolinkfailure)、HandoverFailure(T304HOtimerexpiry)、

ReconfigurationFailure,常見原因為前倆種;

掉線問題分析無MR上報的重建:

現象:表現為業務正常保持時UE發起了RRCConnectionReestablishmentRequest,失敗的原

因是無線鏈路失敗,沒有向系統側發送MR

分析:1.對RSRP和SINR進行分析,如果RSRP較強而SINR較差,則是由于存在干擾(mod3等),如果兩者均差,則主要是覆蓋問題;2.確定是否由于同步保持參數設置過小導致的失步掉話(SIB2消息:T310/N310/T311/N311等);

解決:1.覆蓋及干擾優化;2.修改同步保持參數,增加失步判斷的時間ForUE“normaloperation”inthefigureabovemeans:UEnotwaitingforRRCConnectionSetup/Reject(T300notrunning)UEnotwaitingforRRCRe-establishmentEstablishment/Reject(T301notrunning)handovernotongoing(T304notrunning)NoRLFrecoveryongoing(T311notrunning)NOTE:thetermsin-syncandout-of-syncrefertoL1problems,nottotimingalignment掉線問題分析---RLFduetoT310ExpiryatUEn310consecutiveout-of-syncindicationsn311consecutivein-syncindicationsduringt310RRCconnectionre-establishmentattemptedduringt311CellreselectionandTrackingAreaUpdateifRRCRe-Establishmentfails掉線問題分析有MR上報的重建:

現象:在UE上報重建請求之前最少存在一個MR,在這個過程中可能收到了重配置信令,也有可

能沒有收到重配置信令失敗

分析:1.核查一下鄰區是否存在問題,如果存在同PCI的鄰區則也會出現重建(切換失敗造成),如果存在,就解決鄰區問題進行驗證;2.核查一下RSRP和SINR,確認是否是由于此時覆蓋較差造成MR上報超時(系統側未收到)或是收不到系統側的切換判決;3.確認一下是否收到重配置信令,如果收到則接下來的失敗為隨機接入過程的失??;

解決:1.PCI修改、鄰區優化;2.覆蓋及干擾優化;切換問題分析切換分析主要是針對以下幾個方面進行分析:鄰區漏配鄰區的漏配是指UE發送MR后,在MR內上報的目標切換小區在系統側配置的鄰區表內沒有該小區,這就是鄰區漏配的問題,這些問題會造成路測時的下載流量低、SINR差、發生RRC重建等問題,甚至會造成掉線,在FDD-LTE的系統中,UE并不根據鄰區表進行測試,而是進行全頻段所有可以測量到的小區進行測量,并根據測量對比結果上報前幾個最強的并超過切換門限的小區;

現象:1.多次發送MR;2.MR后系統側無響應;3.SINR較差(一般低于0dB)4.存在RRC重建現象;

分析:1.通過MR獲取切換的目標小區的PCI;2.查詢服務小區的鄰區列表(也可以通過系統側即時獲?。?;3.如果鄰區列表內無該PCI,則為鄰區漏配;4.如果鄰區列表內有該PCI,則為其它原因,轉入其它問題分析。

解決:添加鄰區;(有時通過ANR添加的X2鄰區不起作用,改為c-planeipaddresscontrol->oamcontrolled后正常)切換問題分析切換分析主要是針對以下幾個方面進行分析:鄰區錯配鄰區錯配主要是指在同一個鄰區表內配置了兩個PCI相同的鄰區,或是鄰區的PCI與主服務小區的PCI相同的現象?,F象:1.MR上報后經常切換失敗;2.切換對象可能不是最強的小區,3.SINR較差(低于-3dB)4.測量列表內最少有兩個相同的PCI

分析:只要在測量的小區列表內有兩個或兩個以上的相同PCI,就是該問題。

解決:修改小區PCI切換問題分析切換分析主要是針對以下幾個方面進行分析:乒乓切換乒乓切換主要是指標在切換帶內進行的兩個或多個小區之間反復進行切換,并且切換時間較短。現象:1.下載速率較低;2.SINR較差;3.多次切換(最少3次)分析:該種問題很容易分析,只要兩個或多個小區之間的很小區域內存在多次切換。

解決:抑制各小區的覆蓋區域,減小重疊覆蓋。切換問題分析切換分析主要是針對以下幾個方面進行分析:切換時延切換時延是指控制面的切換時延,時延統計開始于UE收到RRC的重配置信令,結束于UE上報MSG3結束。

現象:控制面切換時延的均值大于目標值(聯通要求小于50ms),這時就會產生切換時延過大的問題。

分析:2個階段來分析1.收到重配后上發MSG1的時延:MSG1重發較多---PRACH及干擾問題2.發出MSG1到收到MSG2(RAR)的時延:干擾問題較多

解決:

1.調整PRACH功率等參數;2.干擾排查及解決;3.調整RS功率等;切換問題分析切換分析主要是針對以下幾個方面進行分析:切換失敗切換切換失敗從事件的信令節點上來說,始于RRCConnectionReconfiguration信令,終于RRC超時并發起重建,對于切換失敗的問題分析時可以結合當時的各種測量指標進行分析,比如RSRP和SINR等測量值。

現象:未發送RRCConnectionReconfigurationComplete,發起RRCConnectionReestablishmentRequest。

分析:1.查看RSRP/SINR/BLER;2.鄰區檢查,主要看是否有相同PCI;3.MSG1發送異常;4.核查同步檢測參數、T304等

解決:

1.調整PRACH參數;2.干擾排查及解決;3.調整RS功率等;切換流程測量報告RRC重配置服務小區測量量鄰區測量量切換命令用戶面時延問題分析用戶面時延

從發出PINGRequest到收到PINGReply之間的時延平均值。

聯通指標要求:32byte,小于30ms

現象:時延超過30ms。

分析:1.查看RSRP/SINR/BLER;

2.查看預調度等參數:

3.服務器配置、狀態等;

解決:

1.覆蓋干擾解決;2.參數優化;3.更換服務器;Note:影響ping時延測試的網絡側配置參數有maxNumPrbSr(40),ilReacTimerUl(當設置為0時為關閉預調度),ulatbEnable(True),iniPrbsUL(40),cellSrPeriod(5ms)。Throughput分析:1.查看小區是否有影響性能的告警、傳輸帶寬等;2.查看RSRP、SINR、Throughput;3.判斷用戶的RB數和DL/ULGrant是否調度充足,如果不充足,首先判斷上層數據源、FTP線程等是否充足(FDD小區單用戶情況下一般穩定在900以上,RB90/slot(20MHz)以上);4.如果DLGrant和RB數都是調度充足的場景下,判斷BLER是否收斂到目標值。目前下行的BLER目標值一般為10%,即5%~15%即認為BLER收斂;5.如果BLER收斂,可判斷是否使用了雙碼字(UE可通過CDS查看用戶的RankIndicator和DLMCS;RI=1單流,RI=2雙流;MCS0~10QPSK/MSC11~2016QAM/MCS21~2864QAM)6.查看參數一致性(64qamenable/16qamenable/

actModulationSchemeUL(16QAMHighMCS)、maxbitratedl/ul

等);7.查看UE能力,測試電腦TCP配置、usb端口、FTP服務器狀態及文件大小等吞吐量問題分析案例分析---鄰區漏配導致的切換失敗案例分析---主時鐘告警導致的切換失敗問題描述:驅車從錫林郭勒南路由南向北行駛,UE占用西五里營1小區(PCI:81),行駛到鋼窗廠2(PCI:41)時沒有切換,一直到鋼窗廠1小區(PCI:39)時最終因干擾導致掉話。問題分析:1.檢查鄰區,未發現鄰區漏配,鄰區里周圍小區都存在;

2.檢查告警,發現基站主時鐘調諧失?。?818:EFaultId_Ov_OscAl)告警;此告警會使基站性能降低,也會影響切換等功能;處理:1:檢查基站和FTM的其他告警并采取相應的措施解決。2:如果基站沒有其他同步相關的告警,通過BTSSitManger啟動fasttune。3:重置該站點,再次啟動快速調整。4:上述操作不奏效,最終更換了BBU。更換前案例分析---IP設置錯誤導致切換失敗問題描述:外場測試人員反映安泰中心(閩星樓)與冠亞廣場無法切換,兩個基站狀態正常、各項指標良好,并與其他基站互切正常。由此猜測故障可能由于兩個基站之間的X2link不可用導致。問題分析:登陸BTSSiteManager,確定兩個基站鄰區關系存在,但是X2linkstatus為unavaiable。檢查發現鄰區關系配置時鄰區基站業務面IP地址

使用的是網管面的ip地址42,導致X2link不可用。配置鄰區時,應該使用Controlplane對應的IP地址。即在新建安泰中心(閩星樓)與冠亞廣場的鄰區關系時,應該使用冠亞廣場ControlplaneIP42。處理:將C-PlaneIPaddressofneighboreNB一欄ip更正為ControlplaneIP42,下發更新基站數據后,X2鏈路狀態變為可用,外場驗證,兩基站能夠正常切換,問題解決。更換前更換后案例分析---UE業務突然中斷問題描述:LTE建網初期基站隨機性出現能夠接入網絡,做業務中突然中斷業務的現象;問題分析:

經與核心網一起查問題后發現出現問題時的UE分配到的IP大多以172.*.*.*開頭,而正常的UE分配到的IP大多以10.*.*.*開頭,172開頭的IP由貝爾PGW分配,10開頭的IP由諾基亞PGW分配,貝爾工程師抓包分析后給出的解釋是;S11接口MME發起的Echorequest消息中的sequencenumber為7位時,貝爾SGW可以正?;貞狤choresponse。當MME發起

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論