1、KPI優(yōu)化提升

KPI性能可以從“網(wǎng)絡(luò)健康度優(yōu)化”和“針對(duì)失敗原因的KPI專項(xiàng)優(yōu)化”兩個(gè)方面進(jìn)行提升。

1.1網(wǎng)絡(luò)健康度優(yōu)化提升

提高網(wǎng)絡(luò)健康度（參數(shù)核查、告警處理、干擾消除）是提升網(wǎng)絡(luò)KPI的基礎(chǔ)，在保障網(wǎng)絡(luò)健康度的前提下針對(duì)相應(yīng)的KPI指標(biāo)再做專項(xiàng)優(yōu)化提升。

表 5-1 網(wǎng)絡(luò)健康度提升Checklist

1.1.1NR PCI規(guī)劃與核查

需要重點(diǎn)核查PCI沖突、PCI混淆、PCI復(fù)用距離。其中造成PCI沖突/混淆可以通過部署“PCI自優(yōu)化”功能來進(jìn)行問題小區(qū)識(shí)別

1.1.1.1PCI沖突

如果使用同一PCI的兩個(gè)同頻5G NR小區(qū)在地理位置上的隔離度過小，則UE在這兩個(gè)小區(qū)的信號(hào)交疊區(qū)域不能正常實(shí)現(xiàn)信號(hào)同步、解碼。如圖1所示，小區(qū)A和B為NR小區(qū)且頻率相同（F1），PCI相同，就出現(xiàn)了Cell A與Cell B的PCI沖突。

圖 5-1 PCI沖突原理圖

? ??

1.1.1.2PCI混淆

兩個(gè)相同頻點(diǎn)、相同PCI的小區(qū)雖然在覆蓋上是隔離的，但卻是同一個(gè)小區(qū)的鄰區(qū)，如果SN Change/切換時(shí)UE上報(bào)了該混淆的PCI，就會(huì)導(dǎo)致UE在切換時(shí)發(fā)生混淆，服務(wù)小區(qū)無法確定UE的切換目標(biāo)小區(qū)，從而導(dǎo)致切換失敗而掉話。

PCI混淆主要發(fā)生在下面的場景：NR同頻小區(qū)間的PCI混淆

圖 5-2 NR同頻小區(qū)間的PCI混淆

? ? ? ? ? ? ? ? ? ? ??

在這種場景下，小區(qū)A和C為NR小區(qū)且頻率相同（F1），PCI相同，且都為NR小區(qū)B的鄰區(qū)。因此，小區(qū)A和C對(duì)小區(qū)B造成了PCI混淆。

1.1.1.3PCI復(fù)用距離

相同PCI最小復(fù)用距離等參數(shù)設(shè)置，推薦配置如下：

1.1.2PRACH規(guī)劃與核查

PRACH相關(guān)參數(shù)配置不合理會(huì)導(dǎo)致MSG1虛檢、MSG1解析錯(cuò)誤等問題，從而影響RRC鏈接建立成功率，PRACH相關(guān)參數(shù)需要核查以下兩方面內(nèi)容：

1、重點(diǎn)核查PRACH相關(guān)參數(shù)是否和《5G無線參數(shù)規(guī)劃操作指導(dǎo)書》推薦參數(shù)配置是否一致，參數(shù)包括：非競爭的隨機(jī)接入前導(dǎo)碼、每個(gè)RACH Occasion的波束個(gè)數(shù)、msg1子載波間隔、競爭解決定時(shí)器時(shí)長、PRACH前導(dǎo)碼個(gè)數(shù)、PRACH頻域RACH Occasion個(gè)數(shù)、頻域RACH Occasion的起始RB、PRACH功率攀升步長、基站期望的前導(dǎo)接收功率、前導(dǎo)最大發(fā)送次數(shù)、基于邏輯根序列的循環(huán)移位參數(shù)(Ncs)、PRACH時(shí)域資源配置索引、用于BFR的基于邏輯根序列的循環(huán)移位參數(shù)(Ncs)。

1.1.3覆蓋優(yōu)化

弱覆蓋可以通過MR數(shù)據(jù)進(jìn)行分析，弱覆蓋站點(diǎn)可以通過調(diào)整天饋、降低發(fā)射功率進(jìn)行優(yōu)化調(diào)整。

超遠(yuǎn)覆蓋可以通過MR數(shù)據(jù)、路測(cè)數(shù)據(jù)、KPI TA統(tǒng)計(jì)進(jìn)行分析。UE從網(wǎng)絡(luò)側(cè)接收TA命令，調(diào)整上行PUCCH/PUSCH/SRS的發(fā)射時(shí)間，目的是為了消除UE之間不同的傳輸時(shí)延，使得不同UE的上行信號(hào)到達(dá)eNodeB的時(shí)間對(duì)齊，保證上行正交性，降低小區(qū)內(nèi)干擾，30KHz子載波間隔1TA≈39m。超遠(yuǎn)覆蓋站點(diǎn)可以通過調(diào)整天饋、降低發(fā)射功率進(jìn)行優(yōu)化調(diào)整。不同子載波間隔對(duì)應(yīng)的TA距離參見下表：

1.1.4定時(shí)器核查

UE側(cè)定時(shí)器為集團(tuán)管控參數(shù)，有明確的其中：

1）T300、T301、T310、N310、T311、T319、T304設(shè)置越大，對(duì)指標(biāo)改善越明顯，建議全網(wǎng)核查：低于集團(tuán)規(guī)范值的站點(diǎn)修改為集團(tuán)規(guī)范值，高于集團(tuán)規(guī)范值的站點(diǎn)為保持指標(biāo)穩(wěn)定暫時(shí)保留；

2）N311、UE不活動(dòng)定時(shí)器設(shè)置越小，對(duì)指標(biāo)改善越明顯，建議全網(wǎng)核查：高于于集團(tuán)規(guī)范值的站點(diǎn)修改為集團(tuán)規(guī)范值，低于集團(tuán)規(guī)范值的站點(diǎn)為保持指標(biāo)穩(wěn)定暫時(shí)保留

3）UE側(cè)定時(shí)器定義詳見附錄

控制面定時(shí)器為廠家私有參數(shù)（非集團(tuán)管控）：控制面定時(shí)器配置過小，可能會(huì)影響無線指標(biāo)；配置過大，若出現(xiàn)異常，UE會(huì)一直占用基站資源，造成資源浪費(fèi)。

1.1.55G內(nèi)系統(tǒng)鄰區(qū)核查

5G內(nèi)系統(tǒng)鄰區(qū)核查內(nèi)容包括：外部小區(qū)參數(shù)配置一致性、鄰區(qū)漏配、超遠(yuǎn)鄰區(qū)核查，建議：

1）開啟系統(tǒng)內(nèi)ANR功能添加漏配鄰區(qū)；

2）根據(jù)鄰區(qū)對(duì)統(tǒng)計(jì)，對(duì)大于2Km且切換成功率為0的小區(qū)進(jìn)行刪除；

3）檢查外部鄰區(qū)參數(shù)（PCI、小區(qū)ID、TAC等）配置是否和小區(qū)實(shí)際配置一致

1.2、KPI分析及優(yōu)化提升

1.2.1無線接通率優(yōu)化提升

1.2.1.1參數(shù)優(yōu)化

1.2.1.1.1PDCCH公共空間EPRE相對(duì)于小區(qū)RE參考功率的偏移

通過優(yōu)化“PDCCH公共空間EPRE相對(duì)于小區(qū)RE參考功率的偏移”可以提升無線接通率。

負(fù)面影響：參數(shù)修改后，為保障PDCCH功率，PDCCH最大可用資源減少，當(dāng)5G用戶過多時(shí)，會(huì)造成PDCCH資源不足。

1.2.1.1.2MSG4不攜帶P0-PUSCH-AlphaSet問題優(yōu)化

在V5.35.30 1230之前的版本中MSG4消息不攜帶P0-PUSCH-AlphaSet，RRC重配之前的上行調(diào)度按照協(xié)議是使用的Msg3/msg1的P0，會(huì)概率導(dǎo)致基站收不到UE的建立完成消息。并且經(jīng)過對(duì)比HW和我司參數(shù)配置，當(dāng)PL<130時(shí)，我司MSG5的發(fā)射功率低于HW區(qū)域，這種情況會(huì)影響RRC連接建立成功率和QoS Flow建立成功率。

最終解決方案：V5.35.30 1230版本，在MSG4下發(fā)功控dedicated。

臨時(shí)解決方案：可以通過修改“MSG3相對(duì)于PRACH的功率配置”進(jìn)行優(yōu)化提升，待版本升級(jí)后再進(jìn)行參數(shù)回退。

備注：該參數(shù)為集團(tuán)規(guī)范參數(shù)，各地根據(jù)實(shí)際情況進(jìn)行修改

MSG4不攜帶P0-PUSCH-AlphaSet問題說明詳見附錄

1.2.1.2RRC連接建立成功率

1.2.1.2.1RRC建立失敗原因解析

RRC連接建立失敗原因包括定時(shí)器超時(shí)、接納失敗、其它原因。

定時(shí)器超時(shí)

當(dāng)gNB由于等待分接入類型的RRC連接建立完成消息(RRCSetupComplete)定時(shí)器超時(shí)后，計(jì)數(shù)器加1。

造成等待定時(shí)器超時(shí)的原因包括：功控參數(shù)設(shè)置不合理、RRU功率異常、弱覆蓋、上行干擾、高CPU利用率。

接納失敗

當(dāng)gNB接收到從UE來的分接入類型RRC連接建立請(qǐng)求(RRCSetupRequest)消息后，由于接納失敗導(dǎo)致RRC連接建立失敗時(shí)，計(jì)數(shù)器加1。

造成接納失敗的原因包括：接納參數(shù)設(shè)置不合理、小區(qū)負(fù)荷過高。

其他原因

當(dāng)gNB接收到從UE來的分接入類型RRC連接建立請(qǐng)求(RRCSetupRequest)消息后，由于gNB內(nèi)部原因（例如CPU沖高）失敗導(dǎo)致RRC連接建立失敗時(shí)，計(jì)數(shù)器加1。

造成該失敗的主要原因可能是由于NR內(nèi)部處理流程異常，需要通過分析失敗信令進(jìn)行問題定位。

1.2.1.2.2影響RRC連接建立成功率的因素

影響RRU接入的主要因素如下，可在優(yōu)化RRC成功率時(shí)參考

基站故障；

PRACH參數(shù)配置，最小接入電平設(shè)置；

上行干擾NI太高；

弱場接入，RRC無法完成；

用戶數(shù)多導(dǎo)致，SR容量不足；

CPU負(fù)荷高

1.2.1.2.3RRC連接建立成功率處理思路

1. 通過統(tǒng)計(jì)分析是否出現(xiàn)RRC接入成功率低的問題，當(dāng)前RRC接通率指標(biāo)要求為99%。

2. 確認(rèn)是否全網(wǎng)指標(biāo)惡化，如果是全網(wǎng)指標(biāo)惡化，需要檢查操作記錄，告警，是否存在網(wǎng)絡(luò)變動(dòng)和升級(jí)行為。

3. 如果是部分站點(diǎn)指標(biāo)惡化，拖累全網(wǎng)指標(biāo)，需要尋找TOP站點(diǎn)。

4. 查詢RRC連接建立最低的TOPN站點(diǎn)及時(shí)間段，細(xì)分失敗原因值。

5. 查看TOPN站點(diǎn)告警，BBU狀態(tài)，小區(qū)狀態(tài)，OMMB操作日志，配置是否異常。

6. 針對(duì)TOP站點(diǎn)進(jìn)行針對(duì)性的信令跟蹤、干擾檢測(cè)進(jìn)行分析。

7. 將信令跟蹤文件，干擾檢測(cè)結(jié)果，操作日志交研發(fā)人員分析。

1.2.1.3QoS Flow建立成功率

1.2.1.3.1QoS Flow建立失敗原因解析

QoS Flow建立失敗原因包括消息參數(shù)錯(cuò)誤、切換引起、空口失敗、其它原因。

消息參數(shù)錯(cuò)誤

gNodeB處理InitialContextSetupRequest、PDU SESSION RESOURCE SETUP REQUEST或PDU SESSION RESOURCE MODIFY RESPONSE過程中，校驗(yàn)消息中的參數(shù)，如果參數(shù)校驗(yàn)失敗，則導(dǎo)致5QI Flow建立失敗。

造成消息參數(shù)錯(cuò)誤的原因可能是由于NR側(cè)和核心網(wǎng)側(cè)對(duì)消息中某些字段理解不一致導(dǎo)致，該問題的排查需要根據(jù)失敗信令進(jìn)行分析。

切換引起

當(dāng)切換流程打斷了PDU Session流程（PDU SESSION RESOURCE SETUP RESPONSE或PDU SESSION RESOURCE MODIFY RESPONSE）造成消息攜帶的QoS Flow Setup Request List中存在某些5QI的QoS Flow異常釋放。

切換引起的Flow建立失敗主要是流程沖突導(dǎo)致，該問題主要通過優(yōu)化信令流程來進(jìn)行規(guī)避。

空口失敗

向AMF發(fā)送了INITIAL CONTEXT SETUP FAILURE、PDU Session Resource Failed to Setup Lis、INITIAL CONTEXT SETUP RESPONSE消息攜帶了一個(gè)或多個(gè)PDU session的QoS Flow Failed to Setup List、PDU SESSION RESOURCE SETUP RESPONSE攜帶了PDU Session Resource Failed to Setup List或PDU SESSION RESOURCE MODIFY RESPONSE攜帶了一個(gè)或多個(gè)PDU session的QoS Flow Failed to Add or Modify List，且失敗原因?yàn)椤翱湛谑　薄?/p>

該問題主要適合基站故障、空口質(zhì)量相關(guān)，需要重點(diǎn)排查：弱覆蓋、重疊覆蓋、過覆蓋、上行干擾、基站告警、基站功率設(shè)置。

1.2.1.3.2影響QOS Flow建立成功率的因素

無線覆蓋環(huán)境較差，如弱場覆蓋，上行NI偏高；

無線參數(shù)設(shè)置錯(cuò)誤，如加密完保算法不合理，接納控制門限過低；

傳輸故障；

系統(tǒng)Bug；

1.2.1.3.3QoS Flow建立成功率處理思路

1. 通過統(tǒng)計(jì)分析是否出現(xiàn)ERAB接入成功率低的問題，目前ERAB接通率指標(biāo)一般為99%。

2. 確認(rèn)是否全網(wǎng)指標(biāo)惡化，如果是全網(wǎng)指標(biāo)惡化，需要檢查操作，告警，是否存在網(wǎng)絡(luò)操作和升級(jí)行為。

3. 如果是部分站點(diǎn)指標(biāo)惡化，拖累全網(wǎng)指標(biāo)，需要查找TOP站點(diǎn)。

4. 查詢ERAB連接建立最低的TOPN站點(diǎn)及時(shí)間段，細(xì)分失敗原因值。

5. 查看TOP站點(diǎn)告警，檢查單板狀態(tài)，小區(qū)狀態(tài)，OMMB操作日志，配置是否異常。

6. 針對(duì)TOP站點(diǎn)進(jìn)行針對(duì)性的信令跟蹤、干擾檢測(cè)進(jìn)行分析。

7. 將信令跟蹤文件，干擾檢測(cè)結(jié)果，操作日志交研發(fā)人員分析

1.2.1.4無線接通率案例解析

1.2.1.4.1EPS Fallback測(cè)控參數(shù)漏配導(dǎo)致5QI[1]建立失敗

問題現(xiàn)象：

某區(qū)域TOP站點(diǎn)3419530 5QI[1] QoS Flow建立成功次數(shù)為0，失敗原因是radioNetwork = 34 : Ngap_CauseRadioNetwork_Root_not_supported_5QI_value。

問題分析

正?；谇袚Q的EPS-Fallback，PDU session resource modify rsponse回復(fù)的消息應(yīng)該是radioNetwork = 34 : Ngap_CauseRadioNetwork_Root_ims_voice_eps_ fallback_or_rat_fallback_triggered。

目前回復(fù)的原因值為34，不是正?；谇袚Q的EPS Fallback信令流程，初步判斷是由于EPS Fallback相關(guān)參數(shù)配置錯(cuò)誤導(dǎo)致。

基于切換的EPS Fallback參數(shù)推薦配置如下表：

核查TOP站3419530的EutranFreqRelation、EutranFreq、FrequencyBandList配置均為空，基本可以判斷是由于相關(guān)測(cè)量參數(shù)未配置導(dǎo)致。

問題解決

把測(cè)量相關(guān)參數(shù)配置添加完成后，QoS Flow建立成功率5QI[1]由0%恢復(fù)到100%。

附錄:EPS FB實(shí)現(xiàn)方式

1.2.2無線掉線率

1.2.2.1定時(shí)器優(yōu)化

UE在非語音業(yè)務(wù)時(shí)，UE狀態(tài)識(shí)別為無線鏈路失敗或拔卡后，延遲通知控制面釋放該UE的時(shí)間。把該定時(shí)器由6s->10s后，可以減少“GNB由于RLF引發(fā)釋放”原因造成的異常釋放次數(shù)，從而改善無線掉線率。

1.2.2.2版本優(yōu)化

在V5.35.30 1130之前的版本中，如果接入過程核心網(wǎng)在初始上下文建立請(qǐng)求消息中沒有攜帶PduSessionResourceSetup IE，基站側(cè)等核心網(wǎng)的pdu session 建立10s超時(shí)，會(huì)觸發(fā)了上下文釋放，釋放原因?yàn)槠渌?，該種情況主要是核心網(wǎng)或終端原因，和無線側(cè)無關(guān)。

在V5.35.30 1130及之后的版本中，新增加了計(jì)數(shù)器“C600050034:Context釋放次數(shù)，GNB由于等待核心網(wǎng)消息超時(shí)”，該計(jì)數(shù)器不再計(jì)為異常釋放。

等待PDU Session超時(shí)問題說明文檔，詳見附錄！

1.2.2.3異常釋放原因解析

異常釋放原因包括：GNB切換失敗引發(fā)釋放次數(shù)、GNB空口失敗引發(fā)釋放次數(shù)、由于小區(qū)關(guān)斷或復(fù)位引發(fā)釋放次數(shù)、GNB由于其它原因引發(fā)釋放次數(shù)和GNB由于RLF引發(fā)釋放。

GNB切換失敗引發(fā)釋放次數(shù)

當(dāng)gNode由于切換失敗發(fā)送UE CONTEXT RELEASE REQUEST消息時(shí)，計(jì)數(shù)器加1。

該問題通常是UE在切換執(zhí)行階段，由于目標(biāo)側(cè)發(fā)生RRC連接重建立或者RRC連接重配完成定時(shí)器超時(shí)等原因，觸發(fā)UE釋放。切換失敗引發(fā)的釋放通常是由于鄰區(qū)配置、弱覆蓋、上下行干擾導(dǎo)致，可通過跟蹤信令排查切換前上報(bào)的MR信息來確認(rèn)問題原因。

GNB空口失敗引發(fā)釋放次數(shù)

當(dāng)gNodeB由于RRC重建立或者RRC重配過程中，等待RRC重建立完成或者RRC重配完成定時(shí)器超時(shí)，給AMF發(fā)送UE CONTEXT RELEASE REQUEST消息時(shí)，計(jì)數(shù)器加1。

該問題通常和干擾、弱覆蓋、重疊覆蓋、RRC重配消息中部分字段和UE理解不一致。

由于小區(qū)關(guān)斷或復(fù)位引發(fā)釋放次數(shù)

如下場景，每存在一個(gè)上下文釋放，計(jì)數(shù)器+1：

1）當(dāng)gNodeB接收到小區(qū)閉塞命令，或者小區(qū)配置信息刪除，給AMF發(fā)送UE CONTEXT RELEASE REQUEST消息時(shí)；2）當(dāng)gNodeB給AMF發(fā)送NG Reset消息時(shí)。該原因造成的異常釋放和告警（閉塞告警、復(fù)位告警）相關(guān)，需要重點(diǎn)排查告警。

備注：V5.35.25 P61版本中存在NR切換到LTE后的正常釋放會(huì)誤統(tǒng)計(jì)為小區(qū)關(guān)斷或復(fù)位引發(fā)的釋放，該問題在V5.35.30版本已解決。

GNB由于RLF引發(fā)釋放

當(dāng)gNodeB由于無線鏈路檢測(cè)失敗，給AMF發(fā)送UE CONTEXT RELEASE REQUEST消息時(shí)，計(jì)數(shù)器加1。

gNodeB檢測(cè)RLF包含以下三種場景：1）50次新傳算一個(gè)窗，窗內(nèi)harqfail比例>50%，統(tǒng)計(jì)為異常窗，連續(xù)10個(gè)異常窗；2）連續(xù)50次harqfail，即連續(xù)錯(cuò)包250個(gè)；3）連續(xù)4個(gè)檢測(cè)窗的平均功率下降20db以上，其中8次SRS測(cè)量作為一個(gè)檢測(cè)窗。

該問題觸發(fā)的異常釋放通常和弱覆蓋、重疊覆蓋、干擾相關(guān)。通過修改“非語音業(yè)務(wù)延遲釋放定時(shí)器：6s->10s”，可改善該種原因造成的掉線。

GNB由于其它原因引發(fā)釋放次數(shù)

當(dāng)gNodeB由于除GNB切換失敗、空口失敗、用戶無業(yè)務(wù)進(jìn)IDLE、RLF外其它原因，給AMF發(fā)送UE CONTEXT RELEASE REQUEST消息時(shí)，計(jì)數(shù)器加1。該問題需要跟蹤信令聯(lián)合研發(fā)做進(jìn)一步分析。

備注：在V5.35.30 1130之前的版本，接入過程核心網(wǎng)如果在初始上下文建立請(qǐng)求消息中沒有攜帶PduSessionResourceSetup IE，基站側(cè)會(huì)等核心網(wǎng)的pdu session 建立，如果10s內(nèi)未收到pdu session 建立請(qǐng)求，會(huì)觸發(fā)了上下文釋放（釋放原因：其它）。該種釋放和無線無關(guān)，和終端和核心網(wǎng)處理相關(guān)，在V5.35.30 1130及之后的版本新增了計(jì)數(shù)器“C600050034:Context釋放次數(shù)，GNB由于等待核心網(wǎng)消息超時(shí)”，該種原因不再計(jì)為異常釋放。

1.2.2.4無線掉線率處理思路

1. 按照掉線率分子，提取細(xì)分原因的計(jì)數(shù)器，查看由那類計(jì)數(shù)器引起的失敗次數(shù)最多，針對(duì)性處理。

2. 正常情況下，某個(gè)小區(qū)周邊都存在鄰區(qū)，如果無線環(huán)境不是很差，都可以通過切換的方式改變服務(wù)小區(qū)。當(dāng)某個(gè)站點(diǎn)缺失鄰區(qū)或者鄰區(qū)添加不合理，會(huì)導(dǎo)致無法切換出而掉死。因此處理掉線率較高的小區(qū)時(shí)，需要核查鄰區(qū)配置是否合理。

3. 核查小區(qū)是否存在超遠(yuǎn)覆蓋，導(dǎo)致覆蓋孤島，無法切換到周邊鄰區(qū)?？梢酝ㄟ^后臺(tái)跟蹤信令，觀察測(cè)量報(bào)告，并補(bǔ)齊漏配的鄰區(qū)。隨后需要對(duì)覆蓋進(jìn)行控制。

4. 對(duì)于因弱覆蓋導(dǎo)致掉線，若終端處于覆蓋邊緣，周圍無可用的NR小區(qū)，可以添加系統(tǒng)間鄰區(qū)，使用切換到4G的方式，減少掉線次數(shù)。但門限設(shè)置需要合理，不能太容易去到4G。

1.2.2.5無線掉線案例解析

1.2.2.5.1等待PDU Session超時(shí)導(dǎo)致異常釋放

針對(duì)GNB由于其它原因引發(fā)釋放，篩選TOP小區(qū)跟蹤信令，結(jié)合信令和CPA打印，基本可以確認(rèn)其它原因的上下文釋放主要是由于接入過程核心網(wǎng)在初始上下文建立請(qǐng)求消息中沒有攜帶PduSessionResourceSetup IE，導(dǎo)致基站側(cè)等核心網(wǎng)的pdu session 建立10s超時(shí)，觸發(fā)了上下文釋放。

該種釋放和無線無關(guān)，和終端和核心網(wǎng)處理相關(guān)，在V5.35.30 1130及之后的版本新增了計(jì)數(shù)器“C600050034:Context釋放次數(shù)，GNB由于等待核心網(wǎng)消息超時(shí)”，該種原因不再計(jì)為異常釋放。FOA 區(qū)域版本升級(jí)后，無線掉線率由0.11%下降到0.39%，其它原因引發(fā)的釋放次數(shù)由1780次下降到338次。

1.2.3系統(tǒng)內(nèi)切換成功率

1.2.3.1系統(tǒng)內(nèi)切換失敗原因解析

切換失敗原因包括切換出準(zhǔn)備失敗和切換出執(zhí)行失敗，具體詳見下表：

切換出準(zhǔn)備失敗，源側(cè)發(fā)生重建立

在切換過程中，由于gNodeB在源小區(qū)或源gNodeB站內(nèi)其他小區(qū)接收到UE的RRCReestablishmentRequest消息或者接收到其他gNodeB發(fā)送的XnRetrieveUe ContextRequest消息，造成切換準(zhǔn)備失敗。

切換出準(zhǔn)備失敗，源側(cè)重建立通常是由于無線覆蓋質(zhì)差導(dǎo)致，需要重點(diǎn)核查干擾、弱覆蓋、超遠(yuǎn)覆蓋和重疊覆蓋。

切換出準(zhǔn)備失敗，等待切換響應(yīng)定時(shí)器超時(shí)

在切換過程中，由于源gNodeB等待HandoverRequestAck消息定時(shí)器超時(shí)，造成切換出準(zhǔn)備失敗。

切換出準(zhǔn)備失敗，等待切換響應(yīng)定時(shí)器超時(shí)通常是由于TAC插花、外部鄰區(qū)參數(shù)配置和小區(qū)實(shí)際配置不一致、XN或是NG鏈路故障。需要重點(diǎn)核查TAC插花、外部鄰區(qū)參數(shù)配置、XN/NG鏈路是否丟包。

切換出準(zhǔn)備失敗次數(shù)，目標(biāo)側(cè)資源不足

在切換過程中由于目標(biāo)側(cè)資源準(zhǔn)備不足，造成切換出準(zhǔn)備失敗。

切換出準(zhǔn)備失敗，目標(biāo)側(cè)資源不足通常和目標(biāo)側(cè)負(fù)荷（用戶數(shù)、CPU利用率）、小區(qū)Cellbar、基站內(nèi)部處理異常相關(guān)。該種原因如果目標(biāo)側(cè)RRC連接最大用戶數(shù)<50、CPU利用率<60%且無Cellbar配置的情況下，建議提故障單轉(zhuǎn)研發(fā)做進(jìn)一步排查。

另外需關(guān)注：高鐵站點(diǎn)在V5.35.30之前的版本如果開啟周期性MR會(huì)導(dǎo)致切換過程中目標(biāo)側(cè)資源不足的情況發(fā)生，建議V5.35.30之前的版本不要開啟周期性MR。

切換出準(zhǔn)備失敗次數(shù)，其它原因

除以上原因外，導(dǎo)致的切換出準(zhǔn)備失敗。

其它原因的準(zhǔn)備失敗，在核查完外部鄰區(qū)參數(shù)配置，如果配置正確需要跟蹤信令確定問題現(xiàn)象，上報(bào)第一響應(yīng)組協(xié)助進(jìn)行分析。

切換出執(zhí)行失敗次數(shù)，源側(cè)發(fā)生重建立

在切換過程中，由于gNodeB在源小區(qū)或源gNodeB站內(nèi)其他小區(qū)接收到UE的RRC ReestablishmentReques消息或者接收到其他gNodeB發(fā)送的XnRetrieveUeContext Request消息，造成切換出執(zhí)行失敗。

切換出執(zhí)行失敗次數(shù)，源側(cè)發(fā)生重建立可能是由于切換CIO配置不合理（建議-3dB~3dB）、覆蓋問題（弱覆蓋、重疊覆蓋、超遠(yuǎn)覆蓋）、干擾、鄰區(qū)漏配。TOP小區(qū)處理時(shí)建議根據(jù)信令判斷發(fā)生切換失敗發(fā)生時(shí)是否是在弱場、是否存在鄰區(qū)漏配、測(cè)量參數(shù)是否不合理。

切換出執(zhí)行失敗次數(shù)，等待UE CONTEXT RELEASE消息超時(shí)

在切換過程中，由于源gNodeB等待目標(biāo)側(cè)小區(qū)的UE Context Release定時(shí)器超時(shí)，造成切換出執(zhí)行失敗。

切換出執(zhí)行失敗次數(shù)，其它原因

統(tǒng)計(jì)發(fā)生除以上原因以外導(dǎo)致從gNodeB切換出執(zhí)行失敗，需要跟蹤信令確認(rèn)問題現(xiàn)象再做針對(duì)性的分析優(yōu)化。

1.2.3.2切換成功率低處理思路

切換過程中包含切換準(zhǔn)備階段，與切換執(zhí)行階段，2個(gè)階段涉及到的因素各不一樣，因此需要分開來處理。

切換準(zhǔn)備失敗，多由外部鄰小區(qū)參數(shù)配置錯(cuò)誤（鄰區(qū)配置正確）或者切換準(zhǔn)備目標(biāo)基站故障引起。

切換執(zhí)行失敗，發(fā)生在切換命令下發(fā)后，終端執(zhí)行時(shí)失敗，與無線環(huán)境，鄰區(qū)配置的合理性強(qiáng)相關(guān)。

對(duì)于整網(wǎng)切換成功率較低的網(wǎng)絡(luò)，需要先分析切換準(zhǔn)備與執(zhí)行那個(gè)導(dǎo)致的失敗次數(shù)較多，再按TOP小區(qū)針對(duì)分析處理。

切換準(zhǔn)備失敗處理

切換準(zhǔn)備失敗需要提取切換準(zhǔn)備相關(guān)的計(jì)數(shù)器分解，查看具體的準(zhǔn)備失敗原因。切換準(zhǔn)備失敗主要關(guān)注鄰區(qū)參數(shù)的正確性，具體包括：

1、切換準(zhǔn)備失敗需要定期核查現(xiàn)網(wǎng)鄰區(qū)數(shù)據(jù),保證數(shù)據(jù)的有效與準(zhǔn)確；

2、現(xiàn)網(wǎng)中鄰區(qū)參數(shù)配置錯(cuò)誤的，如外部小區(qū)定義中與鄰接基站定義不一致的；定期提取規(guī)劃數(shù)據(jù)，進(jìn)行核查；

3、現(xiàn)網(wǎng)中對(duì)異廠家站點(diǎn)鄰區(qū)定義錯(cuò)誤的，需定期索取異常家工參核查；

4、現(xiàn)網(wǎng)中鄰區(qū)基站ID錯(cuò)誤的，即不存在于異廠家網(wǎng)管，也不存在與中興網(wǎng)管中的鄰區(qū)關(guān)系。需要?jiǎng)h除這類鄰區(qū)數(shù)據(jù)；

5、定期核查現(xiàn)網(wǎng)中超遠(yuǎn)鄰區(qū)關(guān)系，以2KM為界，對(duì)于超遠(yuǎn)鄰區(qū)且切換成功率<50%的鄰區(qū)對(duì)暫時(shí)刪除。

切換出執(zhí)行失敗處理

切換執(zhí)行階段失敗同樣需要提取切換準(zhǔn)備相關(guān)的計(jì)數(shù)器分解，查看具體的執(zhí)行失敗原因。

1、切換出執(zhí)行失敗次數(shù)>10次且切換成功率=0的小區(qū)對(duì)，建議刪除同時(shí)開啟系統(tǒng)內(nèi)ANR功能對(duì)鄰區(qū)進(jìn)行重新添加；

2、切換出執(zhí)行失敗次數(shù)>10次且切換成功率<90%,首先核查切換目標(biāo)小區(qū)是否與周邊站點(diǎn)同頻同PCI，如果存在同頻同PCI小區(qū)，進(jìn)行PCI重規(guī)劃；

3、切換出執(zhí)行次數(shù)>10次且切換成功率<90%，核查目標(biāo)基站否存在上行干擾，如果存在上行干擾，即需要進(jìn)行干擾排查。????

1.2.3.3切換成失敗案例解析

1.2.3.3.1NG AP未配置導(dǎo)致切換失敗

11579866-311向11579911發(fā)起Handover Required消息，目標(biāo)側(cè)（11579911）未收到Handover Request消息，AMF直接回復(fù)Handover Preparation Failure消息（cause：ho_failure_in_target_5GC_ngran_node_or_target_system）導(dǎo)致NG切換準(zhǔn)備失敗。

核查目標(biāo)側(cè)11579911的接入信令，目標(biāo)側(cè)收到RRCSetupComplete消息后未發(fā)送Intial UE Messeage給AMF，說明該小區(qū)接入存在異常。

核查目標(biāo)側(cè)11579911 NG SCTP和NG AP配置：NG SCTP配置以及狀態(tài)正常，NG AP未配置。添加NG AP配置后11579866-311向11579911切換恢復(fù)正常。

1.2.3.3.2源側(cè)和目標(biāo)側(cè)AMF配置不一致導(dǎo)致切換失敗

【問題現(xiàn)象】

XN口向目標(biāo)站點(diǎn)發(fā)送切換請(qǐng)求，目標(biāo)側(cè)回復(fù)Xnap_CauseRadioNetworkLayer_Root_ invalid_ AMF_Set_ID原因的準(zhǔn)備失敗，隨后向同一個(gè)目標(biāo)站點(diǎn)再發(fā)NG口的切換請(qǐng)求，并收到Ngap_CauseRadioNetwork_Root_ho_failure_in_target_5GC_ ngran_node_or_ target_system原因的切換準(zhǔn)備失敗。

【原因分析】

針對(duì)這種準(zhǔn)備失敗的原因可能是目標(biāo)側(cè)與源側(cè)配置的AMF不一致，一般外場都會(huì)有多套AMF，全網(wǎng)所有的站點(diǎn)都需要將每條AMF配置全備，不然會(huì)出現(xiàn)切換準(zhǔn)備失敗的問題。

1.2.3.3.3切片配置錯(cuò)誤導(dǎo)致無法切換

【問題發(fā)現(xiàn)】

多維分析-控制面分析--N1N2接口分析巡檢發(fā)現(xiàn)，較多次N2切換失敗，原因?yàn)?/p>

slice-not-supported ，切片不支持，定界為無線

【原因分析】

通過下鉆小區(qū)分析，有多個(gè)小區(qū)存在N2切出失敗問題

以MSISDN 17598808267為例，經(jīng)信令回溯分析，用戶駐留小區(qū)LFSHQ1023利比玻璃-ZWH-2向基站gNB-ID為1069677發(fā)起切換，向AMF發(fā)起切換準(zhǔn)備請(qǐng)求NGAP Handover Required，AMF回復(fù)切換失敗消息，原因?yàn)?切片不支持（slice-not-supported）。

cell_id為4381396994

協(xié)議分析，Slice(s) not supported為NG STEUP或者RAN CONFIGURATION UPDATE流程時(shí)，攜帶的切片AMF都不支持，可能是無線配置問題

網(wǎng)元名稱:APP-HBBADheAMF001BZX-05AZX011
網(wǎng)元類型:AMF
網(wǎng)元ID:1090519041

節(jié)點(diǎn)IP:10.36.82.161&10.36.82.129&24095003:101

網(wǎng)元名稱:APP-HBBADheSMF003BZX-05AZX012
網(wǎng)元類型:SMF
網(wǎng)元ID:1107296263
節(jié)點(diǎn)IP800b1705:301

【問題解決】

Slice(s) not supported為NG STEUP或者RAN CONFIGURATION UPDATE流程時(shí)，攜帶的切片AMF都不支持，可能是無線配置問題，查看小區(qū)LFSHQ1023利比玻璃-ZWH-2和基站gNB-ID為1069677其切片配置中tac與本小區(qū)tac配置不一致，修改后問題解決。

網(wǎng)管截圖：

? ?

? ?

? ??

修改后指標(biāo)統(tǒng)計(jì)：小區(qū)切換正常

審核編輯：湯梓紅