SA常見KPI優化指導書

1、KPI優化提升

KPI性能可以從“網絡健康度優化”和“針對失敗原因的KPI專項優化”兩個方面進行提升。

1.1網絡健康度優化提升

提高網絡健康度（參數核查、告警處理、干擾消除）是提升網絡KPI的基礎，在保障網絡健康度的前提下針對相應的KPI指標再做專項優化提升。

表 5-1 網絡健康度提升Checklist

1.1.1NR PCI規劃與核查

需要重點核查PCI沖突、PCI混淆、PCI復用距離。其中造成PCI沖突/混淆可以通過部署“PCI自優化”功能來進行問題小區識別

1.1.1.1PCI沖突

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

圖 5-1 PCI沖突原理圖

? ??

1.1.1.2PCI混淆

兩個相同頻點、相同PCI的小區雖然在覆蓋上是隔離的，但卻是同一個小區的鄰區，如果SN Change/切換時UE上報了該混淆的PCI，就會導致UE在切換時發生混淆，服務小區無法確定UE的切換目標小區，從而導致切換失敗而掉話。

PCI混淆主要發生在下面的場景：NR同頻小區間的PCI混淆

圖 5-2 NR同頻小區間的PCI混淆

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

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

1.1.1.3PCI復用距離

相同PCI最小復用距離等參數設置，推薦配置如下：

1.1.2PRACH規劃與核查

PRACH相關參數配置不合理會導致MSG1虛檢、MSG1解析錯誤等問題，從而影響RRC鏈接建立成功率，PRACH相關參數需要核查以下兩方面內容：

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

1.1.3覆蓋優化

弱覆蓋可以通過MR數據進行分析，弱覆蓋站點可以通過調整天饋、降低發射功率進行優化調整。

超遠覆蓋可以通過MR數據、路測數據、KPI TA統計進行分析。UE從網絡側接收TA命令，調整上行PUCCH/PUSCH/SRS的發射時間，目的是為了消除UE之間不同的傳輸時延，使得不同UE的上行信號到達eNodeB的時間對齊，保證上行正交性，降低小區內干擾，30KHz子載波間隔1TA≈39m。超遠覆蓋站點可以通過調整天饋、降低發射功率進行優化調整。不同子載波間隔對應的TA距離參見下表：

1.1.4定時器核查

UE側定時器為集團管控參數，有明確的其中：

1）T300、T301、T310、N310、T311、T319、T304設置越大，對指標改善越明顯，建議全網核查：低于集團規范值的站點修改為集團規范值，高于集團規范值的站點為保持指標穩定暫時保留；

2）N311、UE不活動定時器設置越小，對指標改善越明顯，建議全網核查：高于于集團規范值的站點修改為集團規范值，低于集團規范值的站點為保持指標穩定暫時保留

3）UE側定時器定義詳見附錄

控制面定時器為廠家私有參數（非集團管控）：控制面定時器配置過小，可能會影響無線指標；配置過大，若出現異常，UE會一直占用基站資源，造成資源浪費。

1.1.55G內系統鄰區核查

5G內系統鄰區核查內容包括：外部小區參數配置一致性、鄰區漏配、超遠鄰區核查，建議：

1）開啟系統內ANR功能添加漏配鄰區；

2）根據鄰區對統計，對大于2Km且切換成功率為0的小區進行刪除；

3）檢查外部鄰區參數（PCI、小區ID、TAC等）配置是否和小區實際配置一致

1.2、KPI分析及優化提升

1.2.1無線接通率優化提升

1.2.1.1參數優化

1.2.1.1.1PDCCH公共空間EPRE相對于小區RE參考功率的偏移

通過優化“PDCCH公共空間EPRE相對于小區RE參考功率的偏移”可以提升無線接通率。

負面影響：參數修改后，為保障PDCCH功率，PDCCH最大可用資源減少，當5G用戶過多時，會造成PDCCH資源不足。

1.2.1.1.2MSG4不攜帶P0-PUSCH-AlphaSet問題優化

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

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

臨時解決方案：可以通過修改“MSG3相對于PRACH的功率配置”進行優化提升，待版本升級后再進行參數回退。

備注：該參數為集團規范參數，各地根據實際情況進行修改

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

1.2.1.2RRC連接建立成功率

1.2.1.2.1RRC建立失敗原因解析

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

定時器超時

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

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

接納失敗

當gNB接收到從UE來的分接入類型RRC連接建立請求(RRCSetupRequest)消息后，由于接納失敗導致RRC連接建立失敗時，計數器加1。

造成接納失敗的原因包括：接納參數設置不合理、小區負荷過高。

其他原因

當gNB接收到從UE來的分接入類型RRC連接建立請求(RRCSetupRequest)消息后，由于gNB內部原因（例如CPU沖高）失敗導致RRC連接建立失敗時，計數器加1。

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

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

影響RRU接入的主要因素如下，可在優化RRC成功率時參考

基站故障；

PRACH參數配置，最小接入電平設置；

上行干擾NI太高；

弱場接入，RRC無法完成；

用戶數多導致，SR容量不足；

CPU負荷高

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

1. 通過統計分析是否出現RRC接入成功率低的問題，當前RRC接通率指標要求為99%。

2. 確認是否全網指標惡化，如果是全網指標惡化，需要檢查操作記錄，告警，是否存在網絡變動和升級行為。

3. 如果是部分站點指標惡化，拖累全網指標，需要尋找TOP站點。

4. 查詢RRC連接建立最低的TOPN站點及時間段，細分失敗原因值。

5. 查看TOPN站點告警，BBU狀態，小區狀態，OMMB操作日志，配置是否異常。

6. 針對TOP站點進行針對性的信令跟蹤、干擾檢測進行分析。

7. 將信令跟蹤文件，干擾檢測結果，操作日志交研發人員分析。

1.2.1.3QoS Flow建立成功率

1.2.1.3.1QoS Flow建立失敗原因解析

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

消息參數錯誤

gNodeB處理InitialContextSetupRequest、PDU SESSION RESOURCE SETUP REQUEST或PDU SESSION RESOURCE MODIFY RESPONSE過程中，校驗消息中的參數，如果參數校驗失敗，則導致5QI Flow建立失敗。

造成消息參數錯誤的原因可能是由于NR側和核心網側對消息中某些字段理解不一致導致，該問題的排查需要根據失敗信令進行分析。

切換引起

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

切換引起的Flow建立失敗主要是流程沖突導致，該問題主要通過優化信令流程來進行規避。

空口失敗

向AMF發送了INITIAL CONTEXT SETUP FAILURE、PDU Session Resource Failed to Setup Lis、INITIAL CONTEXT SETUP RESPONSE消息攜帶了一個或多個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攜帶了一個或多個PDU session的QoS Flow Failed to Add or Modify List，且失敗原因為“空口失敗”。

該問題主要適合基站故障、空口質量相關，需要重點排查：弱覆蓋、重疊覆蓋、過覆蓋、上行干擾、基站告警、基站功率設置。

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

無線覆蓋環境較差，如弱場覆蓋，上行NI偏高；

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

傳輸故障；

系統Bug；

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

1. 通過統計分析是否出現ERAB接入成功率低的問題，目前ERAB接通率指標一般為99%。

2. 確認是否全網指標惡化，如果是全網指標惡化，需要檢查操作，告警，是否存在網絡操作和升級行為。

3. 如果是部分站點指標惡化，拖累全網指標，需要查找TOP站點。

4. 查詢ERAB連接建立最低的TOPN站點及時間段，細分失敗原因值。

5. 查看TOP站點告警，檢查單板狀態，小區狀態，OMMB操作日志，配置是否異常。

6. 針對TOP站點進行針對性的信令跟蹤、干擾檢測進行分析。

7. 將信令跟蹤文件，干擾檢測結果，操作日志交研發人員分析

1.2.1.4無線接通率案例解析

1.2.1.4.1EPS Fallback測控參數漏配導致5QI[1]建立失敗

問題現象：

某區域TOP站點3419530 5QI[1] QoS Flow建立成功次數為0，失敗原因是radioNetwork = 34 : Ngap_CauseRadioNetwork_Root_not_supported_5QI_value。

問題分析

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

目前回復的原因值為34，不是正?；谇袚Q的EPS Fallback信令流程，初步判斷是由于EPS Fallback相關參數配置錯誤導致。

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

核查TOP站3419530的EutranFreqRelation、EutranFreq、FrequencyBandList配置均為空，基本可以判斷是由于相關測量參數未配置導致。

問題解決

把測量相關參數配置添加完成后，QoS Flow建立成功率5QI[1]由0%恢復到100%。

附錄:EPS FB實現方式

1.2.2無線掉線率

1.2.2.1定時器優化

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

1.2.2.2版本優化

在V5.35.30 1130之前的版本中，如果接入過程核心網在初始上下文建立請求消息中沒有攜帶PduSessionResourceSetup IE，基站側等核心網的pdu session 建立10s超時，會觸發了上下文釋放，釋放原因為其它，該種情況主要是核心網或終端原因，和無線側無關。

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

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

1.2.2.3異常釋放原因解析

異常釋放原因包括：GNB切換失敗引發釋放次數、GNB空口失敗引發釋放次數、由于小區關斷或復位引發釋放次數、GNB由于其它原因引發釋放次數和GNB由于RLF引發釋放。

GNB切換失敗引發釋放次數

當gNode由于切換失敗發送UE CONTEXT RELEASE REQUEST消息時，計數器加1。

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

GNB空口失敗引發釋放次數

當gNodeB由于RRC重建立或者RRC重配過程中，等待RRC重建立完成或者RRC重配完成定時器超時，給AMF發送UE CONTEXT RELEASE REQUEST消息時，計數器加1。

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

由于小區關斷或復位引發釋放次數

如下場景，每存在一個上下文釋放，計數器+1：

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

備注：V5.35.25 P61版本中存在NR切換到LTE后的正常釋放會誤統計為小區關斷或復位引發的釋放，該問題在V5.35.30版本已解決。

GNB由于RLF引發釋放

當gNodeB由于無線鏈路檢測失敗，給AMF發送UE CONTEXT RELEASE REQUEST消息時，計數器加1。

gNodeB檢測RLF包含以下三種場景：1）50次新傳算一個窗，窗內harqfail比例>50%，統計為異常窗，連續10個異常窗；2）連續50次harqfail，即連續錯包250個；3）連續4個檢測窗的平均功率下降20db以上，其中8次SRS測量作為一個檢測窗。

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

GNB由于其它原因引發釋放次數

當gNodeB由于除GNB切換失敗、空口失敗、用戶無業務進IDLE、RLF外其它原因，給AMF發送UE CONTEXT RELEASE REQUEST消息時，計數器加1。該問題需要跟蹤信令聯合研發做進一步分析。

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

1.2.2.4無線掉線率處理思路

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

2. 正常情況下，某個小區周邊都存在鄰區，如果無線環境不是很差，都可以通過切換的方式改變服務小區。當某個站點缺失鄰區或者鄰區添加不合理，會導致無法切換出而掉死。因此處理掉線率較高的小區時，需要核查鄰區配置是否合理。

3. 核查小區是否存在超遠覆蓋，導致覆蓋孤島，無法切換到周邊鄰區?？梢酝ㄟ^后臺跟蹤信令，觀察測量報告，并補齊漏配的鄰區。隨后需要對覆蓋進行控制。

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

1.2.2.5無線掉線案例解析

1.2.2.5.1等待PDU Session超時導致異常釋放

針對GNB由于其它原因引發釋放，篩選TOP小區跟蹤信令，結合信令和CPA打印，基本可以確認其它原因的上下文釋放主要是由于接入過程核心網在初始上下文建立請求消息中沒有攜帶PduSessionResourceSetup IE，導致基站側等核心網的pdu session 建立10s超時，觸發了上下文釋放。

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

1.2.3系統內切換成功率

1.2.3.1系統內切換失敗原因解析

切換失敗原因包括切換出準備失敗和切換出執行失敗，具體詳見下表：

切換出準備失敗，源側發生重建立

在切換過程中，由于gNodeB在源小區或源gNodeB站內其他小區接收到UE的RRCReestablishmentRequest消息或者接收到其他gNodeB發送的XnRetrieveUe ContextRequest消息，造成切換準備失敗。

切換出準備失敗，源側重建立通常是由于無線覆蓋質差導致，需要重點核查干擾、弱覆蓋、超遠覆蓋和重疊覆蓋。

切換出準備失敗，等待切換響應定時器超時

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

切換出準備失敗，等待切換響應定時器超時通常是由于TAC插花、外部鄰區參數配置和小區實際配置不一致、XN或是NG鏈路故障。需要重點核查TAC插花、外部鄰區參數配置、XN/NG鏈路是否丟包。

切換出準備失敗次數，目標側資源不足

在切換過程中由于目標側資源準備不足，造成切換出準備失敗。

切換出準備失敗，目標側資源不足通常和目標側負荷（用戶數、CPU利用率）、小區Cellbar、基站內部處理異常相關。該種原因如果目標側RRC連接最大用戶數<50、CPU利用率<60%且無Cellbar配置的情況下，建議提故障單轉研發做進一步排查。

另外需關注：高鐵站點在V5.35.30之前的版本如果開啟周期性MR會導致切換過程中目標側資源不足的情況發生，建議V5.35.30之前的版本不要開啟周期性MR。

切換出準備失敗次數，其它原因

除以上原因外，導致的切換出準備失敗。

其它原因的準備失敗，在核查完外部鄰區參數配置，如果配置正確需要跟蹤信令確定問題現象，上報第一響應組協助進行分析。

切換出執行失敗次數，源側發生重建立

在切換過程中，由于gNodeB在源小區或源gNodeB站內其他小區接收到UE的RRC ReestablishmentReques消息或者接收到其他gNodeB發送的XnRetrieveUeContext Request消息，造成切換出執行失敗。

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

切換出執行失敗次數，等待UE CONTEXT RELEASE消息超時

在切換過程中，由于源gNodeB等待目標側小區的UE Context Release定時器超時，造成切換出執行失敗。

切換出執行失敗次數，其它原因

統計發生除以上原因以外導致從gNodeB切換出執行失敗，需要跟蹤信令確認問題現象再做針對性的分析優化。

1.2.3.2切換成功率低處理思路

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

切換準備失敗，多由外部鄰小區參數配置錯誤（鄰區配置正確）或者切換準備目標基站故障引起。

切換執行失敗，發生在切換命令下發后，終端執行時失敗，與無線環境，鄰區配置的合理性強相關。

對于整網切換成功率較低的網絡，需要先分析切換準備與執行那個導致的失敗次數較多，再按TOP小區針對分析處理。

切換準備失敗處理

切換準備失敗需要提取切換準備相關的計數器分解，查看具體的準備失敗原因。切換準備失敗主要關注鄰區參數的正確性，具體包括：

1、切換準備失敗需要定期核查現網鄰區數據,保證數據的有效與準確；

2、現網中鄰區參數配置錯誤的，如外部小區定義中與鄰接基站定義不一致的；定期提取規劃數據，進行核查；

3、現網中對異廠家站點鄰區定義錯誤的，需定期索取異常家工參核查；

4、現網中鄰區基站ID錯誤的，即不存在于異廠家網管，也不存在與中興網管中的鄰區關系。需要刪除這類鄰區數據；

5、定期核查現網中超遠鄰區關系，以2KM為界，對于超遠鄰區且切換成功率<50%的鄰區對暫時刪除。

切換出執行失敗處理

切換執行階段失敗同樣需要提取切換準備相關的計數器分解，查看具體的執行失敗原因。

1、切換出執行失敗次數>10次且切換成功率=0的小區對，建議刪除同時開啟系統內ANR功能對鄰區進行重新添加；

2、切換出執行失敗次數>10次且切換成功率<90%,首先核查切換目標小區是否與周邊站點同頻同PCI，如果存在同頻同PCI小區，進行PCI重規劃；

3、切換出執行次數>10次且切換成功率<90%，核查目標基站否存在上行干擾，如果存在上行干擾，即需要進行干擾排查。????

1.2.3.3切換成失敗案例解析

1.2.3.3.1NG AP未配置導致切換失敗

11579866-311向11579911發起Handover Required消息，目標側（11579911）未收到Handover Request消息，AMF直接回復Handover Preparation Failure消息（cause：ho_failure_in_target_5GC_ngran_node_or_target_system）導致NG切換準備失敗。

核查目標側11579911的接入信令，目標側收到RRCSetupComplete消息后未發送Intial UE Messeage給AMF，說明該小區接入存在異常。

核查目標側11579911 NG SCTP和NG AP配置：NG SCTP配置以及狀態正常，NG AP未配置。添加NG AP配置后11579866-311向11579911切換恢復正常。

1.2.3.3.2源側和目標側AMF配置不一致導致切換失敗

【問題現象】

XN口向目標站點發送切換請求，目標側回復Xnap_CauseRadioNetworkLayer_Root_ invalid_ AMF_Set_ID原因的準備失敗，隨后向同一個目標站點再發NG口的切換請求，并收到Ngap_CauseRadioNetwork_Root_ho_failure_in_target_5GC_ ngran_node_or_ target_system原因的切換準備失敗。

【原因分析】

針對這種準備失敗的原因可能是目標側與源側配置的AMF不一致，一般外場都會有多套AMF，全網所有的站點都需要將每條AMF配置全備，不然會出現切換準備失敗的問題。

1.2.3.3.3切片配置錯誤導致無法切換

【問題發現】

多維分析-控制面分析--N1N2接口分析巡檢發現，較多次N2切換失敗，原因為

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

【原因分析】

通過下鉆小區分析，有多個小區存在N2切出失敗問題

以MSISDN 17598808267為例，經信令回溯分析，用戶駐留小區LFSHQ1023利比玻璃-ZWH-2向基站gNB-ID為1069677發起切換，向AMF發起切換準備請求NGAP Handover Required，AMF回復切換失敗消息，原因為 切片不支持（slice-not-supported）。

cell_id為4381396994

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

網元名稱:APP-HBBADheAMF001BZX-05AZX011
網元類型:AMF
網元ID:1090519041

節點IP:10.36.82.161&10.36.82.129&24095003:101

網元名稱:APP-HBBADheSMF003BZX-05AZX012
網元類型:SMF
網元ID:1107296263
節點IP800b1705:301

【問題解決】

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

網管截圖：

? ?

? ?

? ??

修改后指標統計：小區切換正常

審核編輯：湯梓紅