SA組網接入信令流程包括：

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

2. （可選） 尋呼 當網絡側需要和UE建立連接時， 網絡側發起尋呼流程找到UE，僅被叫UE涉及尋 呼過程， 主叫UE不涉及尋呼過程。

3. 隨機接入 隨機接入（RA, Random Access） 是指從UE發送隨機接入前導開始嘗試接入網絡 到UE與網絡間建立起RRC連接之前的過程。

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

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

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

SA接入類故障分析思路

SA接入類問題與傳統LTE接入類問題分析思路類似， 都是依照接入的整體信令流程來進行分析， 逐段確認接入異常出現的信令節點進行核查定界， 以確認最終問題：

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

判斷方法：

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

比如如下， 終端側日志顯示終端已解析到mib， sib， 但是駐留失敗， 導致沒有發起RRC連接。

常見原因：

1 .基站配置非合法GSCN SSB頻點時， 終端側未配置優先接入頻點.

2.NR小區狀態配置異常（重點分析MIB消息中的Cell Bar信元值）.

3.USIM卡開卡問題， 設置了FPLMN等導致終端不發起接入.

接入異常分析階段2——隨機接入失敗

判斷方法：

隨機接入過程仍然需要通過終端側進行觀察。

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

常見原因：

弱覆蓋或干擾導致隨機接入失敗

超小區半徑接入

Prach參數等配置異常或者物理層原因導致接入失敗

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

判斷方法：

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

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

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

RRCSetup后又立即下發了RRCRel， 如圖2；

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

常見原因：

干擾、 弱覆蓋原因導致 RRC NoReply

SRS/PUCCH等資源申請失敗導致RRC REJ

超規格接入導致RRC丟棄

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

判斷方法：

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

常見原因：

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

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

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

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

判斷方法：

查看NG口， 當gNodeB收到AMF發送的INITIAL CONTEXT SETUP REQUEST消息后， 在處理過程中產生錯誤， 導致上下文建立失敗， 在向AMF發送INITIAL CONTEXT SETUP FAILURE消息時， 根據不同原因統計對應指標。

常見原因：

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

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

傳輸原因導致的上下文建立失敗， 需要排查NG-U鏈路情況.

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

判斷方法：

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

常見原因：

1 .傳輸原因導致QosFlow建立失敗， 排查NG-U鏈路及Path是否配置

2.UE不回復重配置完成消息導致PDU Session建立失敗：終端版本不配套或存在干擾、 弱覆蓋情況.

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

問題現象：

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

問題分析

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

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

問題解決

傳輸側原因導致用戶面不通， 傳輸側處理后恢復.

EPS FB原理介紹

駐留在NR的終端有語音業務且NR不能提供VONR時， 由網絡側發起EPS Fallback流程， 使終端通過PSHO or Redirection（攜帶目標頻點） 的方式回落到LTE， 建立VOLTE業務提供語音服務。

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

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

IMS需要支持信令面功能；

EPS Fallback基本呼叫流程

NR用戶始發呼叫：

1 . NR用戶發起語音呼叫請求,向IMS網絡發送INVITE消息， 網絡側通知其回落到LTE網絡.

2. NR用戶回落到LTE 網絡.

3. NR用戶進行VOLTE呼叫流程， 和普通VOLTE用戶無異.

NR用戶終結呼叫：

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

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

2. 尋呼成功后， 被叫側進行媒體專有承載建立過程， NR觸發

EPS fallback回落， 通知NR用戶回落到LTE網絡

3. NR用戶回落到LTE 網絡

4. NR用戶進行VOLTE呼叫流程， 和普通VOLTE用戶無異

EPS FB信令流程

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

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

2、 當終端發起語音需求時， 核心網側會指示基站建立5QI1 ；

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

4、 基站側拒絕5QI1 建立， 并觸發EPS FB；

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

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

7、 切換完成后， 網絡側將建立QCI5用于承載IMS信令；

8、 在LTE側繼續接續VoLTE呼叫；

EPS FB關鍵信元

RRC建立階段關鍵信元

初始上下文階段關鍵信元

拒絕5QI1階段關鍵信元

EPS FB問題案例——5GC問題導致EPS FB被叫高概率無響應

問題現象：

某局點測試時發現EPSFB被叫存在高概率失敗問題， 即主叫正常回落到4G， 但被叫高概率無響應， 導致呼叫無法接通.

問題分析

1 、 UPF看到SBC向被叫終端發送了INVITE消息， 但終端無回應消息.

2、 但通過基站側虛用戶跟蹤及空口LOG分析發現被叫側gNB并未收到呼叫請求.

3、 5GC側進一步核查呼叫信令流程進行情況， 發現SMF收到了INVITE請求， 但未發送至AMF， 經判斷， 是由于SMF與AMF版本不一致導致.

問題解決

SMF版本升級后問題解決.

原文標題：業務天天學| 5G SA日常指標處理思路

文章出處：【微信公眾號：通信頭條】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq