SA組網(wǎng)接入信令流程包括：

1 . 系統(tǒng)消息廣播 系統(tǒng)消息廣播是UE獲得網(wǎng)絡(luò)基本服務(wù)信息的第一步， 通過系統(tǒng)消息廣播過程， UE 可以獲得基本的AS（Access Stratum） 層和NAS（Non-access Stratum） 層信息。

2. （可選） 尋呼 當(dāng)網(wǎng)絡(luò)側(cè)需要和UE建立連接時， 網(wǎng)絡(luò)側(cè)發(fā)起尋呼流程找到UE，僅被叫UE涉及尋 呼過程， 主叫UE不涉及尋呼過程。

3. 隨機(jī)接入 隨機(jī)接入（RA, Random Access） 是指從UE發(fā)送隨機(jī)接入前導(dǎo)開始嘗試接入網(wǎng)絡(luò) 到UE與網(wǎng)絡(luò)間建立起RRC連接之前的過程。

4. RRC連接管理 RRC連接管理包括UE和gNodeB之間的RRC連接建立、 重配、 釋放、 重建過程， 以 及上行失步管理、UE不活動性管理。

5. 上下文管理 RRC連接建立完成后， gNodeB向5GC發(fā)送INITIAL UE MESSAGE， 觸發(fā)NG-C連接 建立并接收UE上下文。上下文管理過程包括UE上下文建立、 修改和釋放過程。

6. PDU會話管理 PDU會話是指UE與數(shù)據(jù)網(wǎng)絡(luò)（DN， datanetwork） 之間的數(shù)據(jù)連接。一個PDU 會話包括若干個QoS流。PDU會話管理是指gNodeB按照QoS要求， 為QoS流建立、 修改和釋放無線數(shù)據(jù)承載和NG-U傳輸隧道的過程。

SA接入類故障分析思路

SA接入類問題與傳統(tǒng)LTE接入類問題分析思路類似， 都是依照接入的整體信令流程來進(jìn)行分析， 逐段確認(rèn)接入異常出現(xiàn)的信令節(jié)點進(jìn)行核查定界， 以確認(rèn)最終問題：

接入異常分析階段1——用戶不發(fā)起RRC連接過程

判斷方法：

基站側(cè)UU口跟蹤沒有RRCSetupReq消息， 需要在終端側(cè)觀察， 終端側(cè)是否有發(fā)起RRC連接過程。

比如如下， 終端側(cè)日志顯示終端已解析到mib， sib， 但是駐留失敗， 導(dǎo)致沒有發(fā)起RRC連接。

常見原因：

1 .基站配置非合法GSCN SSB頻點時， 終端側(cè)未配置優(yōu)先接入頻點.

2.NR小區(qū)狀態(tài)配置異常（重點分析MIB消息中的Cell Bar信元值）.

3.USIM卡開卡問題， 設(shè)置了FPLMN等導(dǎo)致終端不發(fā)起接入.

接入異常分析階段2——隨機(jī)接入失敗

判斷方法：

隨機(jī)接入過程仍然需要通過終端側(cè)進(jìn)行觀察。

UE的Probe跟蹤中還可以從Event List看到接入失敗的打印， RAR超時等：

常見原因：

弱覆蓋或干擾導(dǎo)致隨機(jī)接入失敗

超小區(qū)半徑接入

Prach參數(shù)等配置異?；蛘呶锢韺釉?qū)е陆尤胧?/p>

接入異常分析階段3——RRC建立失敗

判斷方法：

RRC建立失敗主要包括如下三種：

RRC Rej：UU口檢查收到RRCSetupRequest， 沒有下發(fā)RRCSetup， 下發(fā)了RRCSetupRej， 如圖1 ；

RRC NoReply：UU口檢查收到RRCSetupRequest， 下發(fā)了RRCSetup， 但是等待RRCSetupCpmplete超時；或者下發(fā)

RRCSetup后又立即下發(fā)了RRCRel， 如圖2；

RRC丟棄：UU口檢查收到RRCSetupRequest后， 直接丟棄， 沒有進(jìn)行下一步的處理， 如圖3。

常見原因：

干擾、 弱覆蓋原因?qū)е?RRC NoReply

SRS/PUCCH等資源申請失敗導(dǎo)致RRC REJ

超規(guī)格接入導(dǎo)致RRC丟棄

接入異常分析階段4——NgSig建立及NAS異常

判斷方法：

查看NG口， 基站是否有向AMF發(fā)送INITIAL UE MESSAGE， AMF是否有向gNodeB下發(fā)INITIAL CONTEXT SETUPREQUEST、 DOWNLINK NAS TRANSPORT、 UE CONTEXT RELEASE COMMAND的任一條消息。

常見原因：

基站收到MSG5后， 未向AMF發(fā)送 INITIAL UE MESSAGE， 需要基站排查原因.

對于未收到AMF的INITIAL CONTEXT SETUP REQUEST， 排查SCTP是否異常， 以及找AMF確認(rèn)是否有下發(fā).

對于NAS過程異常（REJ， DETACH等） ， 需要找AMF和終端進(jìn)一步定位.

接入異常分析階段5——上下文建立失敗

判斷方法：

查看NG口， 當(dāng)gNodeB收到AMF發(fā)送的INITIAL CONTEXT SETUP REQUEST消息后， 在處理過程中產(chǎn)生錯誤， 導(dǎo)致上下文建立失敗， 在向AMF發(fā)送INITIAL CONTEXT SETUP FAILURE消息時， 根據(jù)不同原因統(tǒng)計對應(yīng)指標(biāo)。

常見原因：

針對N.UECntx.FailEst.NoRadioRes無線資源不足場景， 需要進(jìn)一步排查空口資源情況.

針對N.UECntx.FailEst.UeNoReply UE無響應(yīng)場景， 需要進(jìn)一步排查空口覆蓋、 干擾、 top終端等情況.

傳輸原因?qū)е碌纳舷挛慕⑹。?需要排查NG-U鏈路情況.

接入異常分析階段6——PDU Session建立失敗

判斷方法：

QosFlow建立過程一般由UE在需要向無線網(wǎng)絡(luò)申請服務(wù)時主動發(fā)起， 并通過初始UE上下文建立流程或PDU Session建立流程完成建立。

常見原因：

1 .傳輸原因?qū)е翾osFlow建立失敗， 排查NG-U鏈路及Path是否配置

2.UE不回復(fù)重配置完成消息導(dǎo)致PDU Session建立失?。航K端版本不配套或存在干擾、 弱覆蓋情況.

接入問題案例——傳輸鏈路故障導(dǎo)致PDU Session建立失敗

問題現(xiàn)象：

5G SA場景， 終端反饋無法接入5G。

問題分析

1 、 跟蹤信令消息， 基站收到PDU Session RSRC Setup Req后， 直接給核心網(wǎng)返回了PDU Session RSRC Setup Rsp， 里面攜帶原因值“transport resource unavailable” 。

2、 一般查看NG-U傳輸是否正常， 以及NG-U鏈路是否正常配置。經(jīng)排查在問題時間點存在gNBNG的用戶面故障告警。

問題解決

傳輸側(cè)原因?qū)е掠脩裘娌煌ǎ?傳輸側(cè)處理后恢復(fù).

EPS FB原理介紹

駐留在NR的終端有語音業(yè)務(wù)且NR不能提供VONR時， 由網(wǎng)絡(luò)側(cè)發(fā)起EPS Fallback流程， 使終端通過PSHO or Redirection（攜帶目標(biāo)頻點） 的方式回落到LTE， 建立VOLTE業(yè)務(wù)提供語音服務(wù)。

基于Redirection方式的EPS Fallback回落， 終端回落到LTE之后需要讀取4G側(cè)系統(tǒng)消息， 然后再建立VOLTE業(yè)務(wù)；并且如果在EPS Fallback之前有數(shù)據(jù)業(yè)務(wù)， 也需要在LTE側(cè)重新建立承載以恢復(fù)數(shù)據(jù)業(yè)務(wù)；

基于PSHO方式的EPS Fallback回落， 終端的語音業(yè)務(wù)與數(shù)據(jù)業(yè)務(wù)（如果存在） 一起切換至LTE側(cè)，語音建立時延與數(shù)據(jù)業(yè)務(wù)中斷時延相對較短；

IMS需要支持信令面功能；

EPS Fallback基本呼叫流程

NR用戶始發(fā)呼叫：

1 . NR用戶發(fā)起語音呼叫請求,向IMS網(wǎng)絡(luò)發(fā)送INVITE消息， 網(wǎng)絡(luò)側(cè)通知其回落到LTE網(wǎng)絡(luò).

2. NR用戶回落到LTE 網(wǎng)絡(luò).

3. NR用戶進(jìn)行VOLTE呼叫流程， 和普通VOLTE用戶無異.

NR用戶終結(jié)呼叫：

主叫CN在撥打NR被叫用戶時， 被叫路由分析找到NR被叫用戶所對應(yīng)的I-CSCF地址， 然后呼叫請求通過I-CSCF最終轉(zhuǎn)移到AMF， AMF生成尋呼消息發(fā)送給gNB。

1 . 被叫AMF在收到呼叫請求消息后， 向NR下發(fā)尋呼

2. 尋呼成功后， 被叫側(cè)進(jìn)行媒體專有承載建立過程， NR觸發(fā)

EPS fallback回落， 通知NR用戶回落到LTE網(wǎng)絡(luò)

3. NR用戶回落到LTE 網(wǎng)絡(luò)

4. NR用戶進(jìn)行VOLTE呼叫流程， 和普通VOLTE用戶無異

EPS FB信令流程

現(xiàn)網(wǎng)出現(xiàn)的語音類問題， 多集中在語音不通， 包括主叫的異常導(dǎo)致的失敗， 也有被叫的異常或者尋呼異常導(dǎo)致的失敗，定位此類問題主要熟悉相應(yīng)的信令流程， 看異常流程出現(xiàn)在哪里， 從而進(jìn)行問題的隔離定界。以下是EPS FB的信令流程，供對比參考：

1 、 終端（MO&MT） 駐留在5G， 并建立5QI5；

2、 當(dāng)終端發(fā)起語音需求時， 核心網(wǎng)側(cè)會指示基站建立5QI1 ；

3、 基站會根據(jù)終端能力信息、 配置等決定進(jìn)行EPS FB以及是否測量；

4、 基站側(cè)拒絕5QI1 建立， 并觸發(fā)EPS FB；

5、 基站側(cè)決定以重定向/切換的方式回落到LTE；

6、 回落到LTE接入后， 只要N26接口存在， 則需要進(jìn)行TAU流程， 如果是基于無N26接口的EPS FB， 則需要進(jìn)行attach流程；

7、 切換完成后， 網(wǎng)絡(luò)側(cè)將建立QCI5用于承載IMS信令；

8、 在LTE側(cè)繼續(xù)接續(xù)VoLTE呼叫；

EPS FB關(guān)鍵信元

RRC建立階段關(guān)鍵信元

初始上下文階段關(guān)鍵信元

拒絕5QI1階段關(guān)鍵信元

EPS FB問題案例——5GC問題導(dǎo)致EPS FB被叫高概率無響應(yīng)

問題現(xiàn)象：

某局點測試時發(fā)現(xiàn)EPSFB被叫存在高概率失敗問題， 即主叫正常回落到4G， 但被叫高概率無響應(yīng)， 導(dǎo)致呼叫無法接通.

問題分析

1 、 UPF看到SBC向被叫終端發(fā)送了INVITE消息， 但終端無回應(yīng)消息.

2、 但通過基站側(cè)虛用戶跟蹤及空口LOG分析發(fā)現(xiàn)被叫側(cè)gNB并未收到呼叫請求.

3、 5GC側(cè)進(jìn)一步核查呼叫信令流程進(jìn)行情況， 發(fā)現(xiàn)SMF收到了INVITE請求， 但未發(fā)送至AMF， 經(jīng)判斷， 是由于SMF與AMF版本不一致導(dǎo)致.

問題解決

SMF版本升級后問題解決.

原文標(biāo)題：業(yè)務(wù)天天學(xué)| 5G SA日常指標(biāo)處理思路

文章出處：【微信公眾號：通信頭條】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq