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

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

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

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

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

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

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

SA接入類故障分析思路

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

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

判斷方法：

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

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

常見原因：

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

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

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

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

判斷方法：

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

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

常見原因：

弱覆蓋或干擾導(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超時(shí)；或者下發(fā)

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

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

常見原因：

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

SRS/PUCCH等資源申請(qǐng)失敗導(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， 需要基站排查原因.

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

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

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

判斷方法：

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

常見原因：

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

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

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

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

判斷方法：

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

常見原因：

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

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

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

問(wèn)題現(xiàn)象：

5G SA場(chǎng)景， 終端反饋無(wú)法接入5G。

問(wèn)題分析

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

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

問(wèn)題解決

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

EPS FB原理介紹

駐留在NR的終端有語(yǔ)音業(yè)務(wù)且NR不能提供VONR時(shí)， 由網(wǎng)絡(luò)側(cè)發(fā)起EPS Fallback流程， 使終端通過(guò)PSHO or Redirection（攜帶目標(biāo)頻點(diǎn)） 的方式回落到LTE， 建立VOLTE業(yè)務(wù)提供語(yǔ)音服務(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ǔ)音業(yè)務(wù)與數(shù)據(jù)業(yè)務(wù)（如果存在） 一起切換至LTE側(cè)，語(yǔ)音建立時(shí)延與數(shù)據(jù)業(yè)務(wù)中斷時(shí)延相對(duì)較短；

IMS需要支持信令面功能；

EPS Fallback基本呼叫流程

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

1 . NR用戶發(fā)起語(yǔ)音呼叫請(qǐng)求,向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用戶無(wú)異.

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

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

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

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

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

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

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

EPS FB信令流程

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

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

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

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

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

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

6、 回落到LTE接入后， 只要N26接口存在， 則需要進(jìn)行TAU流程， 如果是基于無(wú)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問(wèn)題案例——5GC問(wèn)題導(dǎo)致EPS FB被叫高概率無(wú)響應(yīng)

問(wèn)題現(xiàn)象：

某局點(diǎn)測(cè)試時(shí)發(fā)現(xiàn)EPSFB被叫存在高概率失敗問(wèn)題， 即主叫正?；芈涞?G， 但被叫高概率無(wú)響應(yīng)， 導(dǎo)致呼叫無(wú)法接通.

問(wèn)題分析

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

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

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

問(wèn)題解決

SMF版本升級(jí)后問(wèn)題解決.

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

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

責(zé)任編輯：haq