LTE切換問題定位和優(yōu)化指導書

1、Huawei Technologies Co. Ltd.華為技術有限公司產(chǎn)品名稱Project ID密級 Confidentiality level項目組名稱 Group name日期Date版本 VersionLTE切換問題定位指導（僅供內(nèi)部使用）For internal use only擬制：LTE性能專家組日期：審核：日期：審核：日期：批準：日期：華為技術有限公司Huawei Technologies Co., Ltd.版權所有 侵權必究All rights reserved概述 錯誤 !未定義書簽。1 切換問題定位思路 錯誤!未定義書簽。切換失敗問題 錯誤!未定義書簽。U或多條測量報告

2、仍沒有收到切換命令 錯誤！未定義書簽。切換過程隨機接入失敗 錯誤!未定義書簽。測量報告丟失 錯誤！未定義書簽。切換命令丟失 錯誤！未定義書簽。下行信道質(zhì)量差導致發(fā)送preamble 達最大次數(shù)仍未收到RAR. 錯誤 ！未定義書簽。eNBTF發(fā)RRCI令等待U取饋，不處理切換命令 錯誤！未定義書簽。X2_IPPATHffi置錯誤導致切換失敗為例進行分析 錯誤！未定義書簽。X2切換，源側(cè)發(fā)出切換請求，沒有收到切換響應 錯誤！未定義書簽。X2切換，目標側(cè)發(fā)送 S1AP_PATH_SWITCH_REQ至IJ響應 錯誤！未定義書簽。X徹換準備時間過長錯過最佳切換時間 錯誤！未定義書簽。S_RSRP N_

3、RSR郵比較高的站內(nèi)切換，用較小的HO_TTT(64ms),可以在信號惡化之前及時進行切換 錯誤 ！未定義書簽。切換門限改小后乒乓切換次數(shù)增多，但是由于切換更加及時，切換失敗次數(shù)減少錯誤 ！ 未定義書簽。CH的析切換問題 錯誤！未定義書簽。站內(nèi)切換，隨機接入失敗導致切換失敗 錯誤 ！未定義書簽。站內(nèi)切換，切換完成丟失導致切換失敗 錯誤 ！未定義書簽。X2切換，源側(cè)等待上下文釋放命令超時 錯誤！未定義書簽。X2切換，SIPathSwitch失敗導致切換失敗 錯誤！未定義書簽。切換隨機接入失敗觸發(fā)重建，重建重配失敗而掉話 錯誤 ！未定義書簽。eN時響應UEU換測量報告，信道質(zhì)量惡化而掉話 錯誤！未

4、定義書簽。切換命令丟失導致切換失敗 錯誤 ！未定義書簽。X2切換，Preamble丟失導致切換失敗 錯誤！未定義書簽。X2切換，目標側(cè)等待S1PathSwitchAck超時導致切換失敗.錯誤！未定義書簽。X徹換，隨機接入失敗觸發(fā)重建，重建完成丟而掉話.錯誤！未定義書簽。站內(nèi)切換，隨機接入失敗觸發(fā)重建，重建失敗而掉話 錯誤 ！未定義書簽。站內(nèi)切換，切換完成丟失觸發(fā)重建，重建失敗而掉話 錯誤 ！未定義書簽。概述無線通訊的最大特點在于其移動性控制，對于終端在不同小區(qū)間的移動，網(wǎng)絡側(cè)需要實時監(jiān)測U商控制在適當時刻命令 UE故跨小區(qū)的切換，以保持其業(yè)務連續(xù)性。在切換的過程中，終端與網(wǎng)絡 側(cè)相互配合完成切

5、換信令交互，盡快恢復業(yè)務，在LTE系統(tǒng)中，此切換過程是硬切換，業(yè)務在切換過程中是中斷的，為了不影響用戶業(yè)務，切換過程需要保證切換成功率、切換中斷時延、切換吞吐 率三個重要指標，其中最重要的是切換成功率，如果切換出現(xiàn)失敗，將嚴重影響用戶感受，切換中 斷時延和切換吞吐率也會不同程度地影響用戶感受。對于網(wǎng)絡中可能出現(xiàn)的切換問題，本文根據(jù)當 前積累的LTE系統(tǒng)內(nèi)切換問題定位經(jīng)驗，給出相應的問題隔離定位指導，以優(yōu)化相應的網(wǎng)絡指標。1切換問題定位思路下面是從LTE切換問題定位和優(yōu)化指導書中摘錄的案例，可供切換問題定位參考。切換信令失敗和切換用戶面中斷時延問題的定位思路圖分別如下：圖1切換信令失敗問題分析思

6、路圖圖2切換用戶面時延問題分析思路圖分析方法對應表切換失敗分類定位方法信道質(zhì)量1通過Probe觀察RSRP SINR、IBLER、DL/UL_Grant等；LMT用戶性能跟蹤，分析上/下行信道質(zhì)量網(wǎng)優(yōu)問題2結合網(wǎng)絡規(guī)劃，分析是否有越區(qū)覆蓋情況，調(diào)整電傾角；cluster邊界鄰區(qū)關系配置。配置問題3MM匿看是否有鄰區(qū)漏配；X2相關配置；隨機接入相關配置( Ncs_Index );鑒權開關傳輸問題4查看告警，是否有鏈路閃斷；傳輸是否穩(wěn)定。該問題概率性出現(xiàn)，很難抓取10g定位產(chǎn)品問題5無線側(cè)、核心網(wǎng)側(cè)產(chǎn)品Bug可能造成切換概率性失?。还δ懿煌晟埔部赡茉斐汕袚Q性能降低。需要開發(fā)協(xié)助定位。切換大時延分類

7、解決方案數(shù)據(jù)包重傳源側(cè)數(shù)據(jù)包CR0昔B060SPC350版本合入：源側(cè) L3收到切換測量報告后，指示L2對之后的數(shù)據(jù)采用低階調(diào)度，MCS#數(shù)可配，同時抬升對應的PDCC助率，固定CCEM合級別為8目標側(cè)數(shù)據(jù)包CRCtB060SPC350版本合入：目的側(cè)切換完成后啟動定時器， 定時器時長內(nèi)對數(shù)據(jù)采用低階發(fā)送，MCS階數(shù)可配（MML可配）；同時抬升對應的 PDCCHJ率，固定CCE聚合級 另 為 8 （合入版本）。SET HOMCSPARAMCSHOSTATIC=0 HOCQIRPTTIMER=60ms;切換命令重傳切換命令HARCM傳進入頻選（代碼bug）B060SPC340版本合入：切換命令

8、HARCM傳時不進入頻選切換命令PDCCH/PDSCH限eRAN B060SPC350版本合入：1）抬升切換命令 PDCC電率，同時固定CCEM合級別為8; 2）抬升切換命令PDSCH 功率，同時切換命令采用固定 MCS1發(fā)送；3） eNB側(cè)直 接將HARQ+ARQ傳（考慮到商用終端能力，該功能默認關閉）；4）合入DTX處理方案，解決初彳解到 DTX HARQ 重傳無增益問題。隨機接入流程Preamble重傳優(yōu)化覆蓋/調(diào)整切換參數(shù)，使得切換點具有較好的信道質(zhì) 量，減少重傳。X2配置問題檢查 X2配置(X2_Interface/IPPATH )等。UE處理流程B060SPC360 UE版本合入：

9、優(yōu)化流程，如果在更新系統(tǒng) 消息期間收到 RRC連接重配置消息，則打斷系統(tǒng)消息更 新流程，優(yōu)先處理 RRC接重配消息。1.1 切換失敗問題1.1.1 UEg多條測量報告仍沒有收到切換命令在ANRF關關閉時，如果不配置鄰區(qū)關系，不能進行切換。首先確認eNB側(cè)配置是否有問題，是否是鄰區(qū)漏配。例如，UE從小區(qū)A往小區(qū)B切換，發(fā)送了切換測量報告；此時，若小區(qū) A沒有配置小區(qū)B為鄰區(qū)，即使收到切換測量報告也不會處理，不下發(fā) 切換命令，導致切換失??；此時，如果UE儂續(xù)往遠離服務小區(qū)的方向移動，信號越來越差會導致掉話。查看是否鄰區(qū)漏配，有如下方法：LST EUTRANEXTERNALCE LL 詢夕卜部小區(qū)）

10、LST EUTRANINTRAFREQNCE LL 詢同頻鄰區(qū)）1.1.2 切換過程隨機接入失敗暫且不考慮信道質(zhì)量差導致的隨機接入失敗，我們首先查看相關的參數(shù)配置是否合理。隨機接 入性能與小區(qū)半徑配置有關系。如果UE&目標小區(qū)最大接入半徑范圍之外的地方發(fā)起隨機接入，很可能出現(xiàn)preamble與RA杯匹配的問題，導致隨機接入失敗。隨機接入失敗的原因是UEW發(fā)送Preamble經(jīng)過無線信道傳輸時延后到達eN眼晚，導致eNodeBj$照正常的接收窗去解 Preamble時解成了上一個Preamble ID ,導致發(fā)送的RA島口 preamble不匹配。出現(xiàn)這種問題時，華為測試終端的OMT:會

11、有如下打印：如果小區(qū)覆蓋范圍較大（比如郊區(qū)），切換點離目標小區(qū)距離大于目標小區(qū)實際配置的小區(qū)半徑，會出現(xiàn)隨機接入失敗導致切換失敗?？梢赃m當增大目標小區(qū)半徑，使得用戶實際位置在小區(qū)半 徑之內(nèi)。1.1.3 測量報告丟失首先判斷測量報告丟失是否為上行信道質(zhì)量差導致，可以通過上面4點進行分析。下面給出下行加載場景下下行信道質(zhì)量差導致切換測量報告發(fā)不出去的案例：現(xiàn)網(wǎng)路測一輪出現(xiàn)8次測量報告丟失，每次的 S_RSRP在-115dBm以內(nèi)，在其它小區(qū)上行空載的 情況下（即上行沒有干擾），-115dBm以內(nèi)不會出現(xiàn)上行受限。因此，不應該是上行信道質(zhì)量差導致的測量報告丟失?，F(xiàn)網(wǎng)路測一輪出現(xiàn)8次測量報告丟失，每次

12、下行信道質(zhì)量較差，SIN時負值，處于解調(diào)門限附近、IBLER不收斂；DL_Grant偏低，下行最大能力灌包的情況下，UE軍至必 DL_Grant應該為1000（999）,DL_Grant偏低說明PDCCH調(diào)有問題；同時，UL_Grant偏低說明很可能是PDCCH調(diào)問題導致UE軍至U 的UL_Grant減少、上行調(diào)度不足。分析相應點的 UL_Grant ：01： 45： PCI56->PCI6502： 08 ： PCI264->PCI295從UE1間消息分析：發(fā)送測量報告時，SRi到最大重傳次數(shù)觸發(fā)隨機接入ID_RRC_MAC_RA_IND且SR蟲發(fā)的隨機接入失敗，啟動 RRCf機接

13、入。S也到最大重傳次數(shù)說明UE&發(fā)送測量報告時沒有解到上行調(diào)度。綜合以上分析，eN時收到測量報告不是因為上行信道質(zhì)量差導致的上行信令丟失，而是下行 加載場景下，下行信道質(zhì)量惡劣，UE軍調(diào)PDCCH錯，沒有解到上行調(diào)度導致測量報告沒有發(fā)出去；是下行信道質(zhì)量差導致的上行信令丟失。同時，我們做了相應的測試來驗證我們的結論：打開上行預調(diào)度后，測量報告發(fā)不出去的次數(shù)明顯減少。1.1.4 切換命令丟失以50%Load woICI酬測數(shù)據(jù)為例:23:45:PCI48->PCI50 U瞇收到切換命令該切換點鄰區(qū)信號陡升 6dB,對服務小區(qū)造成很大的干擾；下行SINRf艮低（-5dB） , UE能

14、正確解調(diào)切換命令?？赏ㄟ^調(diào)整天線、兩個小區(qū)的 CIO使提前切換來解決。1.1.5 下行信道質(zhì)量差導致發(fā)送preamble達最大次數(shù)仍未收到RAR首先分析切換點的信道情況：從路測數(shù)據(jù)統(tǒng)計看，100喻口載場景出現(xiàn)了 12次切換完成eN股有收到的情況。各切換點 S_RSRP 都比較高，在上行空載的情況下， 不會出現(xiàn)上行受限。分析下行信道質(zhì)量，SINR比較低（均為負值）， 且下行舊LERFI攵斂，說明下行100劾口載場景下，下行干擾很大、信道質(zhì)量較差。從OMT蹤打印看，U或送preamble達最大次數(shù)仍沒有收到 RAR如圖：下圖為100%Load_woICIC、100%Load_ICIC場景隨機接入失

15、敗點，與目標站的距離均小于1km=cluster6 小區(qū)覆蓋范圍較小，配置的 Ncs_Index=2（ 相應的最大接入半徑為，不影響隨機接入性能。綜合以上分析，路測數(shù)據(jù)下行加載場景下的切換完成eN時收到，是由于切換隨機接入失敗導致的。下行信道質(zhì)量差，導致 U段有解到RAR當preamble達到最大重傳次數(shù)時，隨機接入失敗。1.1.6 eNEBF發(fā)RR時令等待UEK饋，不處理切換命令eNBF發(fā)了 RRCB令（比如MIMOt配消息），因為下行信道質(zhì)量差，U酸有解調(diào)出來。當滿足切換條件時，UEi報測量報告，而eNBE在等待上一條RRCB令的反饋，因此，不處理測量報告。當下 發(fā)RRCB令達到2s后仍然

16、收不到U取饋，將其釋放，發(fā)送 RRC_CONN_RE息。如下圖：eNBW跟蹤：UEJ跟蹤1.1.7 X2_IPPATIffi置錯誤導致切換失敗為例進行分析路測過程中，發(fā)現(xiàn)站點 OSL35璉續(xù)出現(xiàn)X2切換準備失敗，如圖:從切換準備失敗的原因可以大致看出：傳輸資源不夠或者 沒有配置 IPPATH 或者 IPPATH 中的鄰接點配置錯誤 導致，由于接入的用戶不多，因此應該是IPPATH®置相關。確認方法：1）從eCGI中可以確定基站ID為100123即OSL12霸站，再根據(jù)上報的鄰區(qū) PCI為4的小區(qū)確認是 否屬于123基站，如果是則確定是 123基站，如果不是則查看 PCI為4小區(qū)所在的

17、基站是哪些，逐個排 查；2）查看123基站的X2接口對應的IPPATH否配置，如果配置則確認 X2接口 ID與IPPATH勺鄰接點 ID 是否一致。Step1:查看目標側(cè)基站相應的 SCT班路號（X2SCTPLINKID ；LST SCTPLNKStep2:根據(jù)SCTpit路號，查看相應 X2接口標識（X2INTERFACEIDLST X2INTERFACE;Step3:根據(jù)X雅口標識，查看相應的IP配置是否正確。LST IPPATH經(jīng)過核查，發(fā)現(xiàn)OSL123t然配置了與OSL355X2接口，但是沒有配置相應的IPPATH導致OSL355 向OSL12致送X2切換請求后，收到 X2切換準備失敗

18、消息。配置 X2_IPPATHHh,切換OK1.1.8 X2W換，源側(cè)發(fā)出切換請求，沒有收到切換響應左圖為源側(cè)基站消息跟蹤；右圖為目的側(cè)基站消息跟蹤。,延誤了最佳切eN環(huán)會處理后面有時還會出現(xiàn)這樣的情況：由于源側(cè)收到HANDOVER_REQUEST_ACK（秒級）換時機，導致切換失敗。1.1.9 X2W換，目標側(cè)發(fā)送 S1AP_PATH_SWITCH_REQ!J響應目標側(cè)發(fā)送S1AP_PATH_SWITCH_REQ至IJ響應，導致此次切換失敗。同時, 上報的切換測量報告，導致新觸發(fā)的切換也失敗。1.1.10 X2 切換準備時間過長錯過最佳切換時間從Probe的測試數(shù)據(jù)中看到，UE&上報

19、多次相同測量報告沒有收到切換命令。根據(jù)eN則全網(wǎng)跟蹤信息分析發(fā)現(xiàn)這種情況下源側(cè) eN毆起X2切換請求。eNBU換X2準備時間過了很長時間才收到切換 請求響應；期間，目的側(cè)信號迅速衰減，最終目的側(cè)eN股有接收到切換完成消息、切換失敗。UE重建成功后，eN毆起對DRB勺重配置消息時，U段有收到，eNBiRLC到最大重傳次數(shù)直接釋放用 戶。UEU換失敗后發(fā)起重建，成功后由于沒有接收到DRB勺重配置消息，再次發(fā)起重建，由于第一次重建eNB® RLCi到最大重傳次數(shù)釋放了用戶上下文，U印二次重建被拒絕導致異常釋放。PCI345小區(qū)RSR覆蓋情況良好，在切換X2準備期間，鄰區(qū)信號迅速衰減， 導致

20、UE®機接入失敗， 目的側(cè)沒有收到切換完成，切換失敗。X2準備時間過長導致切換不及時錯過最佳切換時間，導致后續(xù)用戶重建掉話等情況。【解決措施】S1鏈路閃斷、傳輸受限等問題導致的切換失敗，通常是概率性出現(xiàn)，難以定位分析；對路測切 換性能有一定影響。X2準備時間過長從eNB®全網(wǎng)跟蹤上看X2信令傳輸浪費了 3s的時間。分析站點一鍵式日志時沒 有發(fā)現(xiàn)X2鏈路故障的情況：底層 SCTpit路發(fā)出消息后，如果在 1s內(nèi)沒有收到數(shù)據(jù)包的 ACN向應就會 發(fā)起數(shù)據(jù)包重傳，如果連續(xù) 10次重傳失敗就會上報 SCT腕路告警斷開SCTP初步定位是由于X2信令 重傳導致信令傳輸時延增大。經(jīng)過與客

21、戶確認發(fā)現(xiàn)客戶在近期調(diào)整傳輸網(wǎng)絡，導致傳輸性能受到影 響。出現(xiàn)傳輸問題需要及時向客戶確認，以減少不必要問題定位。1.1.11S_RSRR N_RSRP比較高的站內(nèi)切換，用較小的 HO_TTT64m§ ,可以在信號惡 化之前及時進行切換Testi 22 : 55: PCI48->PCI50 切換命令 UE收到分析：1、這次切換為站內(nèi)切換，切換嵐 S_RSRP N_RSR都比較高；在下行加載場景下，目標小區(qū)對 原小區(qū)有較強的干擾。此時導頻 SINR<0dB, DL_IBLER>20%說明切換點下行信道質(zhì)量較差，導致切 換命令丟失。2、切換門限2dB, UEU換測量報告中

22、 N_RSRP- S_RSRP 3dB。這種S_RSRP N_RSR郵比較高的 站內(nèi)切換，在下行加擾場景下，切換點的下行信道質(zhì)量惡劣，需要提高切換觸發(fā)的及時性，在信道質(zhì)量急劇惡化之前完成切換。3、為了提高切換及時性，將 HO_TT由128m箭短至64ms HO_TTT64ms測試結果，在該點切換 成功。提高切換及時性后，上報切換測量報告點的信道質(zhì)量有所改善，SINRM然也有顯著的減低，但仍然有23dB,大于解調(diào)門限；DL_IBLER Z15%基本收斂于目標值10%下行信道質(zhì)量不是很差, 保證了切換命令的正確解調(diào)。如下圖：Test2 23 : 52: PCI48 >PCI50 切換成功（H

23、O_TTT64msTest3 01 : 06: PCI48 >PCI50 切換成功（HO_TTT64ms結論：對于S_RSRP N_RSR嘟比較高的站內(nèi)切換，切換點信道質(zhì)量急劇惡化，需要提高切換的及時性。建議適當改小切換門限（由 3dB縮小為2dB）,縮短切換觸發(fā)時間 TTT （由128ms縮 小為64ms 。1.1.12切換門限改小后乒乓切換次數(shù)增多，但是由于切換更加及時，切換失敗次數(shù)減少在相同路線上進行不同切換門限對比測試（2dBW換vs 3dB切換），有如下結果：1、3dB切換的路測數(shù)據(jù)中，統(tǒng)計的切換次數(shù)為103次；而2dB切換時的切換次數(shù)明顯增大 （130次）。2、2dB切換由于

24、切換門限變小，更容易發(fā)生乒乓切換，從而切換次數(shù)變多。同時，切換門限減 少也提高了切換的及時性，使得 UES下行信道質(zhì)量明顯惡化之前就觸發(fā)切換，提高了切換成功率。1.2 CH用析切換問題及以后版本合入了 CHRU換維測打點，可以通過 CH的析切換問題，以下舉例給出CH用析切換問題的方法。1.2.1 站內(nèi)切換，隨機接入失敗導致切換失敗CH種記錄的釋放原因值為usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT 圖。Step1 : “掉話前最后10條信令”分析備注：目前Insightsharp不支持解析“掉話前最后 10條信令”，需要用內(nèi)部工具 UM

25、A解析。首先在CH碑找到本次掉話的 CallID ,再在UMA并過濾出該CallID的相關記錄。從CHR己錄的掉 話前最后10條信令可以看到，eN蹄待切換完成5s定時器超時后向核心網(wǎng)發(fā)起釋放請求。Step2:分析L2_SRB_LOG判斷UE否收到切換命令切換命令HAR皈饋為ACK說明UE攵到了切換命令，如下圖：Step3 :查找L2_L1_DEDI_PREAMBLE分析切換隨機接入過程是否成功專用Preamble收到了 10條（Preamble最大重傳次數(shù)配置為 10次），說明U豉有U到RARBS行 了Preamble重傳，并且達到最大重傳次數(shù) 10。綜合以上分析可知，本次站內(nèi)切換失敗原因為隨

26、機接入失敗。1.2.2 站內(nèi)切換，切換完成丟失導致切換失敗CH種記錄的釋放原因值為usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT 圖。Step1 : “掉話前最后10條信令”分析eN股切換命令后未收到切換完成。（CHRe取CalllD ,在UMA中過濾出該CalllD信息）Step2:分析L2_SRB_LOG判斷UE否收到切換命令切換命令HAR皈饋為ACK說明UEE攵到了切換命令，如下圖：Step3 :查找L2_L1_DEDI_PREAMBLE分析切換隨機接入過程是否成功專用Preamble收到了 1條，說明UE送一次Preamble即收

27、到了 RAR綜合以上分析，本次切換失敗原因為切換完成丟失。當然，也不能完全排除隨機接入失敗導致 的切換失?。║豉有U到RAR而重發(fā)的Preamble eNB均沒有收到）。1.2.3 X2W換，源側(cè)等待上下文釋放命令超時CH種記錄的掉話釋放原因值為usRelCause: UEM UECNT REL HO OUT X2 REL BACK FAILStep1 : “掉話前最后10條信令”分析最后10條信令顯示：源側(cè)沒有收到目標側(cè)的*2±下文釋放命令，定時器超時（ Timer 15s ）釋放用戶。Step2：切換流程分析1）源側(cè)基站CHRL2_SRB_LOGL示切換命令HAR皈饋為ACK說明

28、UE攵到了切換命令。2）源側(cè)基站CHRcell_RR_RSP字段中查找本次呼叫的 CRNTI=6303）目標側(cè)基站CHRHo In info 字段中查找SRS CRNTI=630勺話單。由于目標側(cè)站點 CH骸時段 信息已被沖掉，因此無法繼續(xù)分析。如果有目標側(cè)的信息，可以分析切換隨機接入是否成功，是否 收到切換完成，etc 。1.2.4 X2W換，SIPathSwitch失敗導致切換失敗Stepl :源側(cè)CH野析1）切換命令HAR超饋為ACK說明UE攵到了切換命令2）該U位切換源側(cè)的CRNTI=1457；3）切換測量報告中的 RSRP S_RSRP=-112dBm； N_RSRP=-108dBm

29、4） “掉話前最后10條信令”分析：等待 X2_Context_Rel_CMD超時釋放用戶，切換失敗。需要 通過目標側(cè)CHR1一步分析切換失敗原因。Step2：目標側(cè)CH用析1）過濾HoInInfo的usSrsCrnti字段，找到usSrsCrnti=1457的記錄，即為該 U訃次切換的目標 側(cè)信息。2 ） “掉話前最后10條信令”分析：目標側(cè)收到了切換完成；由于核心網(wǎng)回復 S1_PATH_SWITCH_REQ_FAIM 切換失敗。綜合以上分析可知，本次切換失敗原因為S1PathSwitch失敗，非無線側(cè)原因。1.2.5 切換隨機接入失敗觸發(fā)重建，重建重配失敗而掉話Step1: “掉話前最后1

30、0條信令”分析，切換失敗重建回源側(cè)，eN爵待重建重配完成超時（5s）釋放用戶。Step2：重建原因分析，切換隨機接入失敗觸發(fā)重建1.2.6 eN陳響應UEU換測量報告，信道質(zhì)量惡化而掉話Step1: “掉話前最后10條信令”分析UE斷上報切換測量報告（切換目標小區(qū)PCI320）,但eN味下發(fā)切換命令（懷疑沒有配置鄰區(qū)關系）；從測量報告信息可知，U斯在服務小區(qū)下彳T信號較弱，RSRP=-122dBmStep2：掉話原因分析UEM UECNT REL UE RLC UNRESTORE INDh*12RLCt傳次數(shù)達至U最大值時的無法恢復指示消息*/該釋放原因包括兩種場景：1) SRB RL(&am

31、p;最大重彳次數(shù)；2) DRB RL位最大重傳次數(shù)。L2_SRB_LOG錄了 L2檢測到異常前(比如，RLCi最大重傳次數(shù))最后 8條下行SRB勺調(diào)度情況；DRB_64MSsize=16 )記錄了 L2檢測到異常(比如，RL(&最大重傳次數(shù))前 16*64ms時間內(nèi)下行DRB勺調(diào)度情況。下圖顯示，掉話前 SRBE常，隨后DRBH現(xiàn)大量NACK/DTX( DRB_64MS416的為NACK/DTX。綜合以上分析可知，eN味響應UEU換測量報告，導致信道質(zhì)量惡化，DRB RL跳最大重傳次數(shù)而掉話(eNB僉測到RLCi最大重傳次數(shù)后約延遲 30s釋放)。1.2.7 切換命令丟失導致切換失敗C

32、H種記錄的掉話釋放原因值為 5,即UEM UECNT REL HO OUT X2 REL BACK FAILStep1 : “掉話前10條信令分析”：源測等待上下文釋放命令超時而釋放用戶。Step2：源測CH的析：切換命令的HAR(1傳次數(shù)達到最大 (ucHarqReTransTimes=4 )且HARQ 反饋狀態(tài)為2 (DTX),說明U豉有收到切換命令。綜合以上分析：本次切換失敗的原因為切換命令丟失。1.2.8 X2W換，Preamble丟失導致切換失敗CH種記錄的掉話釋放原因值為 5,即UEM UECNT REL HO OUT X2 REL BACK FAILStep1 : “掉話前10條

33、信令分析”：源測等待上下文釋放命令超時而釋放用戶。Step2 :源測CH野析：(1)切換命令的HAR©饋為1 (ACK ,說明UE攵到了切換命令。(2)通過 RbCellRrRsp 字段的 usCrnti ,確定源測的 CRNTI=524Step3:目標側(cè)CH-析:(1)通過HoInInfo字段，查找usSRSCRnti=524的話單。(2)目標側(cè)CHR6 L1上報Preamble字段，L2_L3釋放Preamble與分配Preamble的間隔為2s, 說明Preamble丟失。綜合以上分析：本次切換失敗的原因為Preamble丟失。1.2.9 X2W換，目標側(cè)等待S1PathSwitchAck超時導致切換失敗Stepl： "掉話前最后10條信令”分析：源側(cè)等待上下文釋放命令超時釋放用戶。Step2 :源測CH用析：(1)切換命令的HAR超饋為ACK說明UE攵到了切換命令。(2) RbCellRrRsp 字段顯示源測的 CRNTI=1006Step3:目標側(cè)CH用析(1)目標側(cè) CHRHoInlnfo 字段，查找 usSRSCRNTI=1006(2)目標側(cè)最后1