SA異廠家組網(wǎng)模式視頻業(yè)務回落后7s左右業(yè)務掉線問題

1、問題名稱：SA異廠家組網(wǎng)模式視頻業(yè)務回落后7s左右業(yè)務掉線問題2、問題概述：江西贛州移動5GSA網(wǎng)絡(luò)測試，對接愛立信核心網(wǎng)（4G）測試5G網(wǎng)絡(luò)VO視頻業(yè)務，5G網(wǎng)絡(luò)撥打視頻業(yè)務呼叫，回落4G網(wǎng)絡(luò)建立成功，主叫發(fā)現(xiàn)回落后7s左右業(yè)務掉線問題。針對該問題進行端到端問題分析定位。問題現(xiàn)象：江西贛州移動SA異廠家組網(wǎng)，無線設(shè)備華為廠家，4G核心網(wǎng)愛立信廠家，5G核心網(wǎng)網(wǎng)中興廠家，使用兩臺測試終端進行視頻業(yè)務主被叫呼叫，兩臺測試終端分別飛行后成功駐留5G網(wǎng)絡(luò)后，主叫發(fā)起視頻業(yè)務呼叫，被叫接通并保持一段時間，5G網(wǎng)絡(luò)撥打視頻業(yè)務呼叫，回落4G網(wǎng)絡(luò)建立成功，主叫發(fā)現(xiàn)回落后7s左右業(yè)務掉線問題。核心網(wǎng)側(cè)抓包分析：SMF建立專載7/8SMF修改專載8/7SGW修改承載響應成功一條，另一條未響應，最終釋放；SMF和語音PCF均為中興同套設(shè)備，專載下發(fā)都是SMF建立專載和修改專載的順序不一致，需要終端和無線側(cè)配合排查。基站側(cè)抓包分析：MME先建QCI1后建QCI2，之后在同一條消息內(nèi)修改兩個承載，順序為先改QCI2后改QCI1，空口對應兩條RRCNAS消息。終端側(cè)信令流程分析：終端響應了其中一條RRCNAS消息，并成功修改了QCI1另外一條RRCNAS消息因為NASCount錯亂的原因被丟棄基站處理流程分析：由于核心網(wǎng)下發(fā)的ERABMODREQ消息僅僅用于修改ERAB的MBR和GBR信息，不需求修改空口資源，為了節(jié)省空口開銷，在不需要修改空口資源的情況下，基站不再下發(fā)重配消息。ERABMODREQ消息中攜帶的NAS信元，通過單獨的NAS消息下發(fā)。協(xié)議描述分析在協(xié)議36.413中有規(guī)定，基站需要將ERABMODREQ中的NAS信元發(fā)送給終端。但是基站對NAS內(nèi)容并不感知，即基站并不能識別到NAS消息對應的NASCount。上述場景協(xié)議并沒有規(guī)定基站下發(fā)NAS消息的限制，基站實現(xiàn)并未違反協(xié)議。上述流程出現(xiàn)失敗為MME修改順序和建立順序不一致的場景中，協(xié)議針對NAS的流程處理規(guī)定不明確導致基站和終端處理的兼容性問題對比成功正常流程，QCI修改的順序和建立順序一致，業(yè)務測試正常結(jié)論：基于上述分析，在核心網(wǎng)建立ERAB的順序（先建立QCI1再建立QCI2）和修改ERAB的順序（先修改QCI2再修改QCI1）不同，且ERAB修改請求中QCI2和QCI1分別攜帶1條NAS消息的場景中，由于核心網(wǎng)觸發(fā)的ERAB修改流程并不需求修改空口資源，基站下發(fā)NAS消息將核心網(wǎng)發(fā)送的NAS消息發(fā)送給終端，終端檢驗NAS消息先收到大Count再收到小Count后丟棄第二條NAS消息（對應QCI2），承載修改失敗。協(xié)議36.413規(guī)定基站在向UE發(fā)送NAS信息時，基站側(cè)不能解析NAS消息內(nèi)容，即基站并不能識別到NAS消息對應的NASCount。上述場景協(xié)議并沒有規(guī)定基站下發(fā)NAS消息的限制，進而引發(fā)上述協(xié)議兼容性問題。詳細解決方案：本案例通過SA網(wǎng)絡(luò)端到端抓包分析，發(fā)現(xiàn)在核心網(wǎng)建立ERAB的順序（先建立QCI1再建立QCI2）和修改ERAB的順序（先修改QCI2再修改QCI1）不同，且ERAB修改請求中QCI2和QCI1分別攜帶1條NAS消息的場景中，由于核心網(wǎng)觸發(fā)的ERAB修改流程并不需求修改空口資源，基站下發(fā)NAS消息將核心網(wǎng)發(fā)送的NAS消息發(fā)送給終端，終端檢驗NAS消息先收到大Count再收到小Count后丟棄第二條NAS消息（對應QCI2），承載修改失敗。協(xié)議36.413規(guī)定基站在向UE發(fā)送NAS信息時，基站側(cè)不能解析NAS消息內(nèi)容，即基站并不能識別到NAS消息對應的NASCount。上述場景協(xié)議并沒有規(guī)定基站下發(fā)NAS消息的限制，進而引發(fā)上述協(xié)議兼容性問題。解決措施：①NR起呼場景，核心網(wǎng)修改QCI的順序和建立QCI的順序保持一致；或者縮短ERAB修改重試定時器或者拉長釋放時長。②在后續(xù)版本中，基站將考慮增加兼容