1、SA EPS Fallback語音方案流程概述

1、EPS Fallback原理

選擇EPS Fallback作為5G SA的語音方案，是因為考慮到目前5G SA建網初期，5G信號覆蓋還處于初期階段，沒有大規模的覆蓋，而4G的覆蓋已經進入成熟期。

EPS Fallback是指當用戶需要使用語音服務時，5G用戶從5G網絡“切換”或者“重定向”到4G網絡，通過4G網絡使用VOLTE語音服務。

EPS Fallback主要是基于MME和AMF間的N26接口完成4/5G間信令交互。

1.1、EPS FB方案

方案一：使用現網傳統平臺的SGW作為SGW-C和SGW-U的方案，此方案優點是布署快，在建網初期，可以直接利用現網設備，不要考慮SMF調試，以及SMF版本成熟度的問題。

方案二：使用5GC的SMF作為SGW-C，此種方案是后續首選的方案，減少信令和數據節點數，減少時延和引入風險點。

1.2、EPS FB流程：

1.2.1、基于切換的EPS FB

基于切換方式到4G，需要無線網優側配置4G和5G間的鄰區，否則無法進行切換。

1.2.2、基于重定向的EPS FB 即通過TAU到4G的方式。

2、EPS FB和Fast Return路測指標定義

路測測試指標中，與EPS FB相關的主要是EPS FB接入時延和接入成功率、返回成功率。推薦的語音域端到端(主叫到被叫整體)的接入時延、接入成功率、以及返回成功率，路測工具PA的指標定義如下。

EPS FB主叫側指標定義

表1：EPS FB 主叫呼叫成功率

KPI含義	EPS FB主叫呼叫成功率
KPI名稱	EPSFBCallSetupSucRate(MOC)
計算公式	EPSFBCallSetupSucRate(MOC)= EPSFBCallSuc(MOC)次數 / (EPSFBCallSuc(MOC)次數+EPSFBCallFail(MOC)次數）；
單位	%
Assistant位置	KPI -> NR -> Service Integrity
說明	1、EPSFBCallSuc(MOC)次數、EPSFBCallFail(MOC)次數次數定義參考表3； 2、根據回落流程不同，工具也同步做了HO、重定向流程的區分；

表2：EPSFB主叫呼叫建立平均時延

KPI含義	EPS FB主叫平均建立時延
KPI名稱	EPSFBCallSetupAvgDelay(MOC)
計算公式	EPSFBCallSetupAvgDelay(MOC)= EPSFB Call Setup Delay(Connect_MO)累加求平均；
單位	ms
Assistant位置	KPI -> NR -> Service Integrity
說明	EPSFB Call Setup Delay(Connect_MO)定義參考表3

表3 PA工具打點

事件指標打點	工具定義
VoNRCallAttempt(MOC)	UE駐留在NR制式下時發出SIP Invite請求進行判斷，如上圖A點；
EPSFBCallAttempt(MOC)	在VoNR呼叫請求的基礎上，網絡側發起了切換/重定向請求時識別為EPSFB呼叫流程，如右圖B1、B2點；
EPSFBCallSuc(MOC)	在發生呼叫發生EPSFB的基礎上，回落到LTE制式時，收到網側SIP 180ringing時進行判斷，如上圖C點；
EPSFBCallFail(MOC)	在發生呼叫發生EPSFB的基礎上，不滿足正常呼叫流程時進行判斷，如回落失敗或回落成功后未收到180Ringing等，具體以軟件實現為準；
EPSFB Call Setup Delay(Connect_MO)	識別為EPSFB流程的呼叫，振鈴時間減去呼叫發起時間，如上圖C點減去A點；

EPS FB被叫側指標定義

表1：EPSFB被叫呼叫成功率

KPI含義	EPS FB被叫呼叫成功率
KPI名稱	EPSFBCallSetupSucRate(MTC)
計算公式	EPSFBCallSetupSucRate(MTC)= EPSFBCallSuc(MTC)次數 / (EPSFBCallSuc(MTC)次數 + EPSFBCallFail(MTC)次數）；
單位	%
Assistant位置	KPI -> NR -> Service Integrity
說明	EPSFBCallSuc(MOC)次數 、EPSFBCallFail(MOC)次數次數定義參考表3

表2：EPSFB主叫呼叫成功率

KPI含義	EPS FB被叫平均建立時延
KPI名稱	EPSFBCallSetupAvgDelay(MTC)
計算公式	EPSFBCallSetupAvgDelay(MTC)= EPSFB Call Setup Delay(Connect_MT)累加求平均；
單位	ms
Assistant位置	KPI -> NR -> Service Integrity
說明	EPSFB Call Setup Delay(Connect_MT)定義參考表3

表3：PA工具打點定義

事件指標打點	工具定義
VoNRCallAttempt(MTC)	UE駐留在NR制式下時收到SIP Invite請求進行判斷，如右圖A點；
EPSFBCallAttempt(MTC)	在VoNR呼叫請求的基礎上，網絡側發起了切換/重定向請求時識別為EPSFB呼叫流程，如上圖B1、B2點；
EPSFBCallSuc(MTC)	在發生呼叫發生EPSFB的基礎上，回落到LTE制式時，發出SIP 180ringing時進行判斷，如右圖C點；
EPSFBCallFail(MTC)	在發生呼叫發生EPSFB的基礎上，不滿足正常呼叫流程時進行判斷，如回落失敗或回落成功后未發出180Ringing等，具體以軟件實現為準；
EPSFB Call Setup Delay(Connect_MT)	識別為EPSFB流程的呼叫，振鈴時間減去呼叫發起時間，如上圖C點減去A點；

FastReturn 指標定義

表1：FastReturn成功率

KPI含義	快速返回成功率
KPI名稱	LTE2NRFastReturnSucRate
計算公式	LTE2NRFastReturnSucRate= LTE2NRFastReturnComplete次數 / (LTE2NRFastReturnComplete次數 + LTE2NRFastReturnException次數）；
單位	%
Assistant位置	KPI -> NR -> Service Integrity
說明	LTE2NRFastReturnComplete次數 、LTE2NRFastReturnException次數定義參考表3

表2：FastReturn平均時延

KPI含義	FastReturn平均時延
KPI名稱	LTE2NRFastReturnAvgDelay
計算公式	LTE2NRFastReturnAvgDelay = LTE2NR Fast Return Delay累加求平均；
單位	ms
Assistant位置	KPI -> NR -> Service Integrity
說明	LTE2NR Fast Return Delay定義參考表3

表3：工具打點定義

事件指標打點	工具定義
LTE2NRFastReturnBegin	FR流程開始事件；UE無法識別網絡側是否觸發FR流程，根據QCI1專用承載釋放后是否下發異系統測控進行判斷，打點位置參考上圖A點；
LTE2NRFastReturnComplete	FR流程完成事件；在判斷出FR開始的基礎上，返回到NR并且完成注冊時進行判斷，如上圖D點位置；
LTE2NRFastReturnException	FR流程異常事件；在FR流程開始的基礎上，未按照右圖流程返回，如切換重定向失敗、注冊失敗等場景時進行判斷，具體以軟件實現為準；
LTE2NR Fast Return Delay	FR成功時間點減去FR開始時間點，如上圖D點減去A點時間；

3、SA異常事件優化

1、接入專題

(1)接入原理：

（2）信令流程排查：

RRC建立階段，上下文建立階段類似和LTE類似，這里主要針對SA的PDUsession建立失敗進行詳細的說明：

lPDUsession建立失敗定義：

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

lPDUsession建立失敗判斷方法：

1、檢查UE是否有發出PDUSessionEstablishmentRequest消息(此為NAS消息)，若未發出，需要終端側進一步分析。

2、檢查NG口AMF是否有發送PDU Session Resource Setup Request消息，若沒有，找AMF進一步分析。

3、檢查UU口Qos是否建立成功，NG口是否有給AMF響應PDU Session Resource Setup Response，若未有，則基站進一步分析。

4、PDU Session Resource Setup Response中若有攜帶原因值，則PDU Session建立失敗，需要根據原因值進一步分析。

lPDUsession建立失敗定位方法

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

2.UE不回復重配置完成消息導致PDU Session建立失?。?/p>

a)UE接收重配置消息但是解碼錯誤導致一直不回復重配置完成消息，一般是版本不配套導致UE解碼出錯。

3.版本是否配套可以查詢：

a)干擾、弱覆蓋

b)已知問題

2、切換專題

SA切換的場景主要分為三種：1、站內同頻切換 2、基于Xn接口的NR站間切換 3、基于NG接口的NR站間切換

l站內同頻切換

1.UE把測量報告發給gNB的源小區=-=-=> 在UU接口體現為RRC MEASUREMENT REPORT信令

2.gNB的源小區收到MR之后，會進行切換判決。

3.如果源小區允許切換，則下發切換命令 =-=-=>在UU接口體現為RRC CONNECT RECONFIG信令，包括NR RRC配置消息（NR切換命令）。

4.UE接收到RRC重配置消息后完成重配置，并向gNB的目標小區反饋RRCConnectionReconfigurationComplete 消息，包括NR RRC響應消息。若UE未能完成包括在RRCConnectionReconfiguration 消息中的配置，則啟動重配置失敗流程。

5.UE收到切換命令后，中斷與源小區的交互，并嘗試接入目標小區，這個過程稱為隨機接入過程。

l基于Xn接口的NR站間切換

1.UE把測量報告發給SgNB =-=-=> 在UU接口體現為RRC MEASUREMENT REPORT信令

2.SgNB判斷是站間切換，SgNB收到MR后進行切換目標小區選擇、準入和資源準備后如果允許切換，通過Xn口給TgNB發送Handover Request消息，請求目標側為UE分配資源。

3.TgNB允許切換后向SgNB回復Handover Request Acknowledge消息。SgNB準備執行切換動作。。

4.SgNB觸發UE應用新的配置。SgNB向UE發送重配置RRCConnectionReconfiguration消息，包含TgNB生成的RRC配置信息。UE更新配置后向TgNB回復RRCConnectionReconfigurationComplete消息，包括對TgNB的RRC響應消息。若UE未能完成包括在RRCConnectionReconfiguration 消息中的配置，則啟動重配置失敗流程。

5.UE在TgNB發起隨機接入。

6.如果TgNB資源分配成功，則向AMF發送PATH SWITCH REQ消息，請求變更路由。

7.AMF回復PATH SWITCH REQ ACK消息，確認路由變更完成。

8.SgNB在收到UE Context Release Command消息后可以釋放空口資源及控制面相關資源，數據轉發不受影響。

l基于Ng接口的NR站間切換

1.UE把測量報告發給源gNB =-=-=> 在UU接口體現為RRC MEASUREMENT REPORT信令

2.源gNB判斷是站間切換，SgNB收到MR后進行切換目標小區選擇、準入和資源準備后如果允許切換，通過Ng口給AMF發送Handover Required消息，包含目標SgNB ID信息等。

3.AMF通過Ng口發送Handover Request消息給TgNB請求目標側為UE分配資源。

4.TgNB允許切換后向AMF回復Handover Request Acknowledge消息。

5.AMF向SgNB發送Handover Command消息，SgNB準備執行切換動作。

6.SgNB觸發UE應用新的配置。SgNB向UE發送重配置RRCConnectionReconfiguration消息，包含TgNB生成的RRC配置信息。UE更新配置后向TgNB回復RRCConnectionReconfigurationComplete消息，包括對TgNB的RRC響應消息。若UE未能完成包括在RRCConnectionReconfiguration 消息中的配置，則啟動重配置失敗流程。

7.UE在TgNB發起隨機接入。

8.如果TgNB資源分配成功，則向AMF回復Handover Notify消息，確認切換完成。

SgNB在收到UE Context Release Command消息后可以釋放空口資源及控

制面相關資源，數據轉發不受影響

切換問題定位思路：

3、掉話專題

掉話原理：SA場景掉話從基站信令上看，分為基站發起的釋放和AMF發起的釋放。SA的釋放分

為上下文，PDUSession，對應的信令流程分別如下。

上下文釋放（基站發起）涉及流程：

圖1基站標準接口信令面上下文釋放

PduSessionRealseReq信令流程如下所示，當然上下文釋放流程也會包含

PduSessionRelaseReq流程；

圖2基站標準接口PduSession釋放呈現

5G中，協議架構變成了分段的處理，核心網上不再有承載概念，具有相同Qos屬性（5G中Qos屬性用5QI表示，無QCI）的業務流稱為一個Qos flow，gNB與UE之間仍然采用承載的概念，由gNB控制將Qos flow放在哪個承載上。Qos flow與空口Radio bearer可以是多對一的映射關系，也可以是1:1的映射關系

QOSFlow的釋放流程沒有專門對應的流程，是包含在：UE上下文釋放流程、

PduSeeion釋放、PduSeeion修改流程里面

如下提供了一組小區不可用導致基站發起釋放的一組示例：可以看到基站檢測到小區

不可用，基站側發起上下文釋放請求；

圖3小區不可用導致掉話信令呈現

NR SA 掉話的場景如下：

4、EPS FB&Fast Return專題

EPS FB&Fast Returan原理

lEPS FB

當前19B/20A版本NR不能成熟支持VoNR，當UE有語音需求時，將通過EPS FB回落到LTE進行VOLTE（當前協議不支持二級回落到UMTS/GSM進行語音），EPS FB回落LTE支持以下3種方式：

（1）基于測量的切換方式；

（2）基于測量的重定向方式；

（3）基于盲的重定向方式（20B支持）；

（4）異常情況（測量超時/切換準備失敗）導致的盲重定向；

lFast Return

在VoLTE語音釋放后，5G開戶用戶測量NR小區（19B用戶僅針對獲取到UE NR歷史信息UE可以觸發fast return，因此僅基于切換EPS FB回落的用戶，且在LTE沒有發生跨站切換時才可以觸發fast return），如果符合切換門限，再fastreturn通過重定向/切換（切換20A開始支持）返回NR小區，數據業務繼續體驗5G網絡。

EPS FB特性流程

駐留在NR的終端有語音業務且NR不能提供VoNR時，由網絡側發起EPS FB流程，回落到LTE，建立VoLTE業務提供語音服務。

EPS FB流程如下（切換方式）：

EPS FB從流程上來講主要有如下策略：

?從EPS FB是否測量LTE來看，19B/20A版本僅支持基于測量的方式，20B版本支持盲重定向的方式，19B/20A版本以下情況將執行盲重定向到LTE：

（1）EPS FB保護定時器超時仍未收到異系統B1測量報告時；

（2）LTE小區切換準備嘗試失??；

?從EPS FB執行方式來區分可以分為如下兩種：

（1）基于重定向的EPS FB：終端回落到LTE之后需要讀取4G側系統消息，建立RRC連接，然后建立VOLTE業務，并且如果在EPS FB之前有數據業務，也需要在LTE側重新建立承載以恢復數據業務；

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

（3）如果同時打開PSHO和重定向，則優先走PSHO；

	基于重定向的EPS FB	基于PSHO的EPS FB
成功率	基于重定向方式的回落，UE選擇質量較好的LTE小區接入，成功率與LTE VOLTE建立成功率基本相當	基于切換方式的回落，切換的執行（比如UE上報測量報告存在延遲），在移動性場景可能會影響切換成功率；基于CSFB回落經驗，基于切換方式的回落成功率略低于基于重定向方式的回落成功率；
時延	基于重定向方式的回落會先釋放業務，然后重新建立，信令流程較多，相對于基于切換方式的回落時長大約多220ms	基于切換方式的回落業務通過CN轉到LTE，信令流程較少，相對于基于重定向方式的回落時長大約短220ms
數據業務影響	數據業務會中斷，回落到LTE之后重新建立業務恢復，中斷時長較長	數據業務通過CN轉到LTE，中斷時長較短
網規要求	需要配置LTE鄰頻點與鄰區，但是對鄰區準確性要求較低，網規難度較低	需要配置LTE鄰頻點與準確的LTE鄰區，網規難度較大
對核心網要求	可不需要N26接口（當前無N26接口的方式協議定義還未完善，且依賴于終端實現，推薦有N26接口），推薦配置N26接口	需要配置N26接口

Fast return特性

Fast return特性主要目的是加快EPS FB用戶業務結束后返回NR小區的速度，提升用戶體驗。

19B版本支持基于測量重定向的方式進行Fast return，20A版本支持基于測量切換的方式進行Fast return。

Fast return具體流程如下：（切換場景）

1)當用戶完成VoLTE語音業務，并刪除語音業務承載后，判斷UE是否支持NR和NGC（（1）判斷終端能力是否支持NR；（2）判斷UE的初始上下文/上下文修改信息中的handover restriction list，只要核心網沒有將NR列為禁止名單，則認為在5G已開戶），如果支持NR和NGC，當前版本還會判斷UE攜帶的業務QCI的切換屬性，當存在MUST HO且不存在NO HO的QCI時，轉下一步；

2)eNodeB下發異系統B1事件測量；

3)UE收到eNodeB的測量配置，進行異系統NR測量。

a.如果測量NR信號在InterRatHoNrParamGrp.NrB1B2TimeToTrigger內持續大于InterRatHoNrParamGrp.ServBasedNrB1RsrpThld，則UE上報事件測量報告，選擇過濾后信號質量最好的NR小區作為目標小區/頻點；

b.如果eNodeB在InterRatHoNrParamGrp.NrB1B2TimeToTrigger超時后，還未收到異系統B1事件上報，則終止異系統B1事件，不再繼續后續操作。

4)UE收到NR目標小區或目標頻點信息后，完成到NR小區的切換或重定向，如果同時打開切換和重定向，則優先走切換。

EPS FB&Fast return策略推薦：

NR2L回落LTE頻點優先級推薦原則：

?室外錨點頻點優先級最高：可添加SCG，多錨點時，按照錨點優先級排序，提升5G占用率。

?無錨點則優先覆蓋/語音層頻點：提回落成功率，避免語音二次回落，或則可以開啟語數分層的回落機制，即語音業務和數據業務分別設置回落LTE頻點優先級（20B支持）。

?室內室分頻點優先級最高：確保業務連續性

以杭州移動NSA雙錨點為例，按錨點優先級配置NR回落L頻點優先如下：

制式	頻段	NSA錨點	NR2L回落優先級
NR	2.6G	NA	7
LTE	FDD 1800	錨點	6
TDD 1900	錨點	5
TDD 2300	非錨點	3
TDD 2600	非錨點	3

如為語數分層場景，則優先回語音承載頻點或語數分層回落（20B），避免二次切換；

EPS FB，NR2L鄰區配置策略：

1、針對共扇區的鄰區配置：

①首先繼承共扇區的LTE小區的鄰區關系；

②如超配置8個LTE頻點之外的LTE鄰區，予以刪除；

③針對所有LTE鄰區相加超過384個（19B/20A/B規格），則根據以下原則刪除：

a)首先根據切換次數進行排序，切換少的優先刪除；

b)如果獲取不到切換次數，則根據拓撲關系進行刪除；

2、針對非共扇區的鄰區配置（包括新建站），則根據拓撲關系進行鄰區添加，注意版本鄰區規格，針對桿站等覆蓋較小的站點，其拓撲關系中距離也應相應減小（如桿站200m/宏站800m）。

3、在GC使用NR&L鄰區規劃時，為了保證NR

L2NR場景頻段優先級策略：

現階段NR側基本為單一頻段，在L2NR頻率優先級配置中，NR側頻率優先級配置為

最高優先級。

在NSA和SA雙模場景，推薦開啟SA B1優選功能，使SA終端盡量先占用SA網絡。

（NSA_SA_MEAS_OBJ_PREEMPTION_SW-1）。

注：目前我司終端可實現雙模場景，SA B1優先功能，其他終端待確認。

信令流程核查：

EPS FB成功率排查流程：

分析動作	分析結果（是）	分析結果（否）
分析動作1：當路測統計發起EPS FB呼叫時，主叫UE發送ESR后，NR側是否成功建立RRC	進入分析動作2	確認當前NR RF情況，如果RF正常且RRC建立失敗或無響應，則需要參考NR隨機接入失敗的定位方法，隔離NR側問題
分析動作2：主叫NR gNodeB側是否發送測量控制	進入分析動作3	（1）對于未下發B1測控問題，需要查詢對應NR站點的配置文件，查詢對應小區的移動性開關、EPSFB開關是否開啟VoiceStrategySwitch=EPS_FB_SWITCH-1, InterRatServiceMobilitySw=MOBILITY_TO_EUTRAN_SW-1; （2）排查EPS FB開關打開以后，需要從配置文件中核查下該站點4G鄰區是否添加，若4G鄰區未添加且NR2LTE ANR 是否開啟，若兩者都沒有生效，也會導致測量控制未下發 （3）排查配置是否配置4G鄰區的異頻頻點且外部鄰區頻點的優先級是否為推薦的優先級策略
分析動作3：下發B1的測量控制以后，在一定時間內UE B1測量報告是否上報	進入分析動作4	（1）在配置文件命令中，查找對應小區< EpsFbProtectionTimer >確認是否存在B1測量報告上報的判決周期，確認設置的判決周期是否為推薦值。若判決周期設置過短，UE還沒有來得及，gNodeB就對UE進行盲重定向了。 （2）在配置文件中，查找當前小區的EPS FB門限配置EpsFbB1RsrpThld 和EpsFbB1Hyst。，UE測量的鄰區Cell RSRP要大于EpsFbB1RsrpThld+EpsFbB1Hyst*0.5，是否此門限配置的合理，若此門限配置的不合理，就會導致周邊無符合條件的小區 （3）若B1的測量門限按照推薦值進行的設置，請檢測LTE小區是否弱覆蓋或者小區故障
分析動作4：UE B1測量報告上報后，NR側是否觸發N2L切換或者重定向	進入分析動作5	(1)檢查此小區是否配置外部鄰區 GNBEUTRAEXTERNALCELL: Mcc=460, Mnc=20, EnodebId=XX, CellId=XX, DlEarfcn=XX, PhysicalCellId="&N11&", Tac=1;" (2)檢查此小區是否配置鄰區關系 ADD NRCELLEUTRANRELATION: NrCellId="&E10&", Mcc=460, Mnc=20, EnodebId=XX, CellId=XX;" (3)LTE 的鄰區存在PCI沖突 (4)以上都沒有問題，要在gNodeB信令跟蹤下，是否為5GC核心網導致的切換命令未下發 (5)如果所有的鄰區切換準備失敗，則根據NRCellEutranNFreq.Priority 盲重定向至LTE小區
分析動作5：主叫UE是否在LTE發起RRC接入，并且成功建立RRC	進行分析動作6	1.UE是否發起RRC連接請求，需要分析此時LTE側的RF情況，是否無合適小區接入。 2.UE已經發起RRC接入，但多次發送網絡側無響應（未收到針對該用戶的RRC connection setup消息），此時上行存在問題，需要核查是否正常 3.UE已經發起RRC接入，但被eNodeB拒絕，要確認是否存在擁塞導致準入失敗
分析動作6：主叫UE是發起TAU流程，TAU消息完成	進入分析動作7	1.UE若收到TAU Reject 消息，則需要在核心網MME側進行信令跟蹤。判斷TAU Reject的原因
分析動作7 :被叫是否收到 Paging消息。	進入分析動作8	1.主叫都正常時，如果長時間沒有呼叫成功，則問題可能出在被叫側，通過主叫時間點找到被叫信令相應時間點前后，確認被叫UE是否收到paging消息 2.并且分析此時被叫UE是否有其他流程，具體請參考5章節的典型場景分析，如果被叫沒有其他流程但仍舊未收到paging消息，則需要跟蹤核心網AMF和gNodeb側信令來隔離是核心網問題還是gNodeb問題
分析動作9：主叫UE是否成功收到Update/180 ring 消息	進入分析動作10	1.一般IMS側的問題都是有相應的錯誤碼判斷建立失敗原因 487 Request Terminated IMS 在發現異常后用487 Request Terminate 終止呼叫 481 CALL/Traction Does Not Exist IMS 收到UE發送消息后，發現呼叫已不存在，發此錯誤碼 480 Terporarily Unavailable IMS 長期得不到UE響應，相關定時器超時發此錯誤嗎 486 Busy Here 當成功聯系到被叫方的終端系統，但是被叫方當前在這個終端系統上不能接聽這個電話（如正在或其他呼叫業務），發此錯誤碼 500 Server Internal Error 服務器遇到未知的情況，并且不能繼續處理請求，一般為IMS內部問題或和其他網元交互異常 503 Service unavailable 服務不可用，一般為IMS內部問題或和其他網元交互異常 603 Decline 尋呼到被叫后，被叫在摘機前終止此次呼叫，一般發此錯誤碼

EPS FB呼叫建立時延排查流程：

以下分別介紹EPS FB語音呼叫流程圖，包含了SIP消息和L3信令部分，針對呼叫建立時延問題，主要采用流程分段來進行分析。

?N2L切換的EPS FB

分段1：NR側RRC Request – NR側Invite

此段主要為UE在idle 狀態下發起業務先進行RRC建鏈過程。主要核查下此空口覆蓋或者干擾原因，導致空口丟包，進而導致時延。

分段2：SIP消息Invite – SIP消息100 trying

此段時延在現網發生的概率是比較大的。主要是UE與IMS的 P-CSCF（SBC）之間的SIP信令流程造成的。在P_CSCF收到主叫的invite消息以后，先給UE發送100 trying,然后再與PCF交互。此段時延比較大時，可在主叫的P_CSCF上抓包后反饋給IMS維護工程師處理。

分段3：SIP消息100 Trying -– B1測量控制下發RRCReconfiguration

主叫側收到100trying以后，網絡側P_CSCF（SBC）向5GC，gNodeB請求專有承載的建立，gNodeB根據配置拒絕QCI=1的建立并觸發EPS FB 的流程。此時gNodeB 向UE發送B1測量控制消息。此段時延較大，主要在P_CSCF（SBC），SMF、AMF以及gNodeB上進行

抓包，看那塊信令結點上處理時延比較大。重點關注 SMF與AMF處理流程。

分段4：B1測量控制RRCReconfiguration –B1測量上報MeasurementReport

此處影響時延主要是UE收到B1的測量控制以后，UE是否很快的上報了測量報告。

如果此段時延比較大，主要原因為UE內部對外部信號測量機制導致，為終端原因?；驘o線覆蓋弱，異頻頻點配置不合理等原因。

分段5：B1測量上報MeasurementReport – 切換命令MobilityFromNRCommand

該段時延主要涉及到gNodeB 收到B1測量報告以后，選擇切換小區，通過AMF、N26接口、MME 、eNodeB 預留切換資源。中間異系統的網元較多，可通過單用戶抓包分析，在此過程中，那個結點在處理過程中時延較長。

分段6：切換命令MobilityFromNRCommand – 切換完RRCConnectionReconfigurationComplete

此段主要是切換執行階段，如果時延較長，主要考慮空口因素導致的時延增加。例如覆蓋抖降等場景

分段7：切換完成RRCConnectionReconfigurationComplete – TAU Request

此段主要為UE在LTE側入網過程中接入、UE能力查詢階段，此過程要考慮空口的覆蓋、干擾影響的時延外，還需要考慮

分段8：TrackingAreaUpdateRequest---–TrackingAreaUpdateComplete

此段時延較大，主要為核心網側的原因，聯系5GC核心網的工程師在AMF、SMF網元跟蹤數據包，分析處理結點時延較大的。

分段9：TrackingAreaUpdateComplete – 183 Session Progress

此段時延較大，主要為被叫側的引入的，從PA數據可以查看被叫側時處于IDLE狀態還是Connect狀態。以及被叫P_CSCF與PCF之間的交互時延等。從杭州測試過程分析來看，這部分時延相對比較穩定，未出現時延比較大的情況。

分段10：183 Session Progress –UPDATE

此段時延較大，主要為主被叫媒體面編解碼協商的過程，從測試中此階段時延出現問題的可能性較小。要關注主被叫UE、以及主被叫P_CSCF（SBC）對編解碼處理的時延。

分段11：UPDATE – 180 Ring

此段時延較大，主要為SIP信令面的交互。優先排查主被叫空口是否由于覆蓋、干擾、切換等因素導致時延變大。

Fast Return成功率排查流程：

分析動作	分析結果（是）	分析結果（否）
分析動作1：當 EPS FB 呼叫在QCI為1承載結束以后，主叫LTE eNodeB側是否發送測量控制	進入分析動作2	(1)對于未下發B1測控問題，需要查詢對應LTE站點的配置文件，查詢對應小區的移動性開關、FastReturn開關是否開起 HoAllowedSwitch=INTER_RAT_MOBILITY_TO_NR_SW-1; HoAllowedSwitch=FAST_RETURN_TO_NR_SW-1; HOMODESWITCH=NrRedirectSwitch-1&NrHoSwitch-0; （2）排查FastReturn開關打開以后，需要從配置文件中核查下該站點5G鄰區是否添加，若5G鄰區未添加且LTE2NR2 ANR 是否開啟，若兩者都沒有生效，也會導致測量控制未下發 （3）排查配置是否配置5G鄰區的異頻頻點且外部鄰區頻點的優先級是否為推薦的優先級策略 (4)上述排查都正確的情況下，請檢查下UE的切換策略。切換策略中對于存在的QCI有必須切換且沒有不能切換的承載，則UE此時可以進行切換的。通過< CNOPERATORQCIPARA>字段，查到各個QCI的，對應的 >，如下QCI5，對應的“ServiceIrHoCfgGroupId”為2。再通過 >，查詢對應組的interRatHoState配置，如下截圖中，切換組“ServiceIrHoCfgGroupId”為2，對應的異系統切換策略“InterRatHoState”為2，Must HO。 5）QCI1釋放后，進行是否有異系統B1下發的判決，判決的周期由參數“CellHoParaCfg.VolteHoNrDelayTimer”來決定，在該周期內判斷是否有異系統B1下發。 在該小區的MML配置文件中，查詢中的配置值，單位為100毫秒。
分析動作2：下發B1的測量控制以后，在一定時間內UE B1測量報告是否上報	進入分析動作3	（1）在配置文件中，查找當前小區的EPS FB門限配置, NrB1B2Hysteresis=2, ServBasedNrB1RsrpThld=-120。UE測量的鄰區 Cell RSRP要大于ServBasedNrB1RsrpThld + NrB1B2Hysteresis *0.5，是否此門限配置的合理，若此門限配置的不合理，就會導致周邊無符合條件的小區 （2）若B1的測量門限按照推薦值進行的設置，請檢測周邊NR小區是否弱覆蓋或者小區故障 （3）若上述都沒有問題的話，需要排查UE問題。
分析動作3：UE B1測量報告上報后，LTE側是否觸發L2NR切換或者重定向	進入分析動作4	(1)檢查此小區是否配置外部鄰區 (2)檢查此小區是否配置鄰區關系 (3)NR 的鄰區存在PCI沖突 (4)以上都沒有問題，要在eNodeB信令跟蹤下，是否為5GC核心網導致的切換命令未下發
分析動作4：主叫UE是否在NR發起RRC接入，并且成功建立RRC	進行分析動作5	(1)UE是否發起RRC連接請求，需要分析此時NR側的RF情況，是否無合適小區接入。 (2)UE已經發起RRC接入，但多次發送網絡側無響應（未收到針對該用戶的RRC connection setup消息），此時上行存在問題，需要核查是否正常 (3)UE已經發起RRC接入，但被gNodeB拒絕，要確認是否存在擁塞導致準入失敗
分析動作6：主叫UE是發起注冊更新流程，注冊更新消息完成	進入分析動作7	2.UE若收到注冊更新失敗消息，則需要在核心網AMF側進行信令跟蹤。判斷更新失敗的原因