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

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