1、重慶移動eSRVCC切換指標分析報告交換中心核心網維護部2016年3月10日、前言隨著VoLTE業務的逐漸商用化， VoLTE用戶數和業務量持續增長，eSRVCC的切換量也隨之持續增長。但是，目前重慶移動的eSRVCC切換成功率指標還不理想，在集團的排名也很靠后。這是 3月8日全天的指標統計數據：時間SRVCC切入請求次數SRVCC切入取消次數SRVCC切入接受次數SRVCC切入接受率SRVCC切入完成次數SRVCC切入完成率SRVCC切入成功次數SRVCC切入成功率2016/3/8186097185899.89%90848.82%62933.82%為此，交換中心核心網維護部開展了對eSRVC

2、C切換的專項優化工作，對當前指標的現狀進行了詳細分析，以期對今后的優化工作提供指向性的信息。、eSRVCC切換涉及的主要接口F圖是一次正常eSRVCC切換的標準流程:*©口 心I SarvwrFE jiukril uTR!<nl 堵七起切a:Q NVTTE注01為BJN弓們MV1E屣待mift合話 僮克疊話捲人賓EPCtt S.-P-GW，/iBUrryatimTHarJor 圈qjlrd hanawflFf 活目沖:Vr.-5M2.槪妙傅它園UJFM/GEFt-N*E- JTfiAN可見，在eSRVCC切換流程中，eMSC （上圖紅圈內，也稱 SRVCC IWF ）主要涉及到

3、 3 個接口（上圖黃圈內）的業務處理：1）Sv接口。eMSC與MME之間的接口，采用 GTP協議。在這個接口上， eMSC接收eNodeB發來的切換請求，并返回目標小區的相關信息，與E接口一起協助 UE完成從4G向2G的切換。2）E接口。eMSC與目標MSC之間的接口，采用 MAP協議。在這個接口上， eMSC將收到的切換請求轉發給目標MSC，并接收目標小區的相關信息，完成局間切換流程，與Sv接口一起協助UE完成從4G向2G的切換。（注：若目標小區與eMSC 處于同一 POOL內，則只需要進行局內切換。）3）Mw 口。eMSC與SBC/ATCF之間的接口，采用 SIP協議。在這個接口上， eM

4、SC 將切換用戶的信息轉發給 ATCF，ATCF再和IMS域內SCC AS完成會話的轉移。可見，eMSC在eSRVCC流程中處于一個十字路口的地位，而上述3個接口中的信令消CQGS47這個eMSC的角息也反映了切換流程中的各種關鍵信息。因此，本報告也主要從度，對當前的eSRVCC指標現狀進行分析。三、eSRVCC指標的計算公式(一)計算公式根據集團公司規定的計算公式，eSRVCC存在以下2個比較重要的指標：eSRVCC成功率=SRVCC切入成功次數/SRVCC切入請求次數eSRVCC完成率=SRVCC切入完成次數/SRVCC切入請求次數(二)公式解讀1 .分母：SRVCC切入請求次數觸發點：e

5、MSC從MME收到PS to CS Request消息。2.分子：SRVCC切入完成次數觸發點：eMSC 向 MME 發送 SRVCC PS to CS Complete 消息。SRVCC切入成功次數觸發點：eMSC 向 MME 發送 SRVCC PS to CS Complete 消息，且 eMSC 收到IMS域ATCF發來的2000K消息。這是因為，整個 SRVCC的過程包括兩個 相對獨立的環節：(1) 承載切換。無線承載從4G向2G的切換。(2) 會話轉移。會話從IMS域向CS域的轉移。只有這兩個環節全部成功，才表示SRVCC過程最終成功。四、eSRVCC切換失敗分析F面是一次正常eSR

6、VCC切換的信令交互流程:嵌EJ出 Ml£ AP工昭亠ATCF At k-S-CSCF A4TCW AMMl AS.- 3CC A3_AR樹方啰訕"冃無勺j童或的 AULI HtUW5.ADD REPLY£L£MAP PRE°AtE HAHDCE2 SRVCC 噸nhg Q5 RgqpiL FJijrMrTkAf-!llT.lmt FRMIP*TOP9 R#i 5»ee h RwuestaEj k1Ift.ADD RFQ17 MAP PRFP.pF HAnr(VFRn%rJXAD RQ:e MOO REQ” MD REP営 1冃nit

7、FRMIPI.ADC FLEPILYAMrlcT11 *D0 REPUf«fl SRV«*ATCF1 ifra蟲傳;端點:灣斤IhIVrTE(1)27 MOD REQpa MC43 REPLJREO30 NTFYREPLYCSRBK新A$ioc4ihc*n 匸 sd/t f33 *R(|l0Cd !>fPr CWiEflijklINCilMjWIGWAMMV WEIHD 朗0 3M3曲如疔也I止1aspsioCdHpterw.事mi.Mnti*aban:)r atet&根據成功率的計算公式：當eMSC收到PS to CS Request消息（上圖紅框消息），分

8、母開始計數。當eMSC收到200 OK消息、且發出 SRVCC PS to CS Complete消息（上圖藍框消息1、2），分子開始計數。而eMSC收到200 OK消息和發出 SRVCC PS to CS Complete消息，是2個相對獨立的過程。其中：是否收到200 OK，主要取決于 SBC/ATCF對會話信息及狀態的判斷。這個過 程主要通過 Mw接口實現。是否發出Complete消息，主要取決于局間（或局內）切換是否正常完成、UE是否已成功接入到目標 2G小區。這個過程主要通過 Sv接口及E接口實現。F面，我們就在不同的接口上，對上述2個過程進行深入分析。（一） Mw 接口從上面的信令

9、流程圖來看，Mw接口的信令交互較為簡單，正常情況下只有Invite、 100、200這3條消息即完成交互，似乎不會有什么失敗的情況。但是，3月8日的兩個關鍵指標SRVCC完成率和成功率之間存在著15%左右的差值（這個差值就是發出Complete消息卻沒有收到 200 OK的次數），表明這個接口上仍然存在一定的失敗情 況。1. 失敗原因匯總為此，我們連續多日在 CQGS47上對Mw接口的SIP消息進行了持續的全量跟蹤, 并對各種異常的情況進行了匯總分析。匯總結果如下：消息次數占比發出的Invite消息2252200 OK for Invite164373.00%183 Session Progr

10、ess48621.60%480 Temporarily Unavailable37516.70%487 Request Terminated1858.20%408 Request Timeout160.70%491 Request Pending140.60%從上表可見，eMSC收到的200 OK （for Invite ）消息僅有73%，其余還出現了 183、 480、487、408、491共5種響應消息。我們結合 VoLTE信令監測系統、貝爾IMS鏡像 消息，對上表中出現的各自響應消息依次進行了詳細分析。2.183響應消息a. 失敗場景：現網Mw接口上出現183消息的情況較多。我們從中抽取

11、了部分消息，根據切換用戶號碼搜索到IMS域內對應的完整消息，發現所有ATCF返回183消息的場景都是呼叫尚處于振鈴階段 （無論發生切換的號碼是主叫方還是被叫方都如此）。注：這種振鈴階段發生的SRVCC也稱為aSRVCC。b. 失敗原因：對于aSRVCC的場景，ATCF不會直接返回200 OK，而是首先返回183消息。只有當被叫接聽電話后，才會返回200 OK消息。否則，就將記為一次 eSRVCC切換失敗。c. 解決思路：從上面的分析可見，按照現有的算法，aSRVCC場景的切換成功與否， 完全取決于被叫用戶的用戶行為，具有不合理的因素。 為此，集團公司已對算法進行了修正：aSRVCC切換場景的切

12、換成功次數統計的觸發點為：eMSC向MME發送SRVCC PS to CS Complete 消息，且 eMSC 收到 IMS 域 ATCF 發來的 Info 消息。從現網抓取的消息來看，aSRVCC流程基本上都收到了Info消息（用于告知切換用戶的振鈴狀態及主被叫狀態）。因此，如果采用新算法，aSRVCC基本都可以成功。據華為公司反饋，包含新算法的eMSC補丁有望在3月底左右加載，屆時即可解決此問題。3.480響應消息a. 失敗場景：現網Mw接口上出現480消息的情況也較多。我們采用相同的方法分析，發現ATCF返回480消息的場景有2種：呼叫尚處于振鈴前階段。 在被叫尚未振鈴的時候 （未返回

13、180 ring）， 主叫發生 SRVCC切換（這種振鈴階段發生的SRVCC也稱為bSRVCC）,呼叫處于拆線階段。在呼叫正在拆線時，主叫或被叫發生SRVCC切換，ATCF返回也會480 Temporarily Un available。但是這種場景發生 的概率極低。b. 失敗原因：對于bSRVCC的場景，目前集團公司尚無相應的切換流程規范，此 場景切換必然失敗，eMSC也不可能收到200消息。對于拆線階段的切換，由于ATCF或SCC AS上已無呼叫的會話信息，因此切換也必然失敗。c. 解決思路：由于尚無bSRVCC切換的流程規范，現階段只要發生 bSRVCC必然切換失敗， 故解決的思路只能放

14、在如何盡量避免發生bSRVCC切換上：縮短接續時延。 接續時延越短，發生 bSRVCC的概率就越低。但是 目前volte域內互通的接續時延已控制在34秒左右，與 cs域互通的接續時延也已經過長期的優化，與網間用戶互通的接續時延又取決于其他運營商的接續速度，可見能夠提升的空間都不大。改善LTE網絡覆蓋。顯然，LTE信號覆蓋越好，發生 bSRVCC的概 率也越低，從而減少失敗的發生。4.487響應消息a.失敗場景:出現487消息的占比同樣不容忽視。分析后發現，ATCF返回487消息的場景也都與振鈴階段的 aSRVCC有關：振鈴期間如果主叫或被叫提前掛機，貝UATCF向eMSC返回487消息。b.

15、失敗原因：由于主叫或被叫提前掛機，此場景下ATCF必然不會返回200 OK，按照現在的統計算法，這將被記為一次切換失敗。c. 解決思路：由于是aSRVCC場景，采用新的算法后，此場景也基本能夠記為成功切換。5.408響應消息a. 失敗場景：出現408消息的占比很小。分析發現，ATCF返回408的場景也與振鈴階段的aSRVCC有關：如果被叫久叫不應，則ATCF向eMSC返回408消息。b. 失敗原因：由于被叫最終沒有接聽電話，此場景下ATCF必然無法返回200 OK，按照現在的統計算法，這將被記為一次切換失敗。c. 解決思路：由于是aSRVCC場景，采用新的算法后，此場景也基本能夠記為成功切換。

16、6.491響應消息a. 失敗場景：出現491消息的占比較也極小。目前對于出現此消息的原因尚未完全梳理清楚，后續將繼續關注分析。b. 失敗原因：此場景下 ATCF 返回 409 Request Pending（其中包含 Warning 信息:transaction inprogress on SAL,懷疑出現了某種流程沖突導致Invite請求被掛起），因此被記為一次切換失敗。c.解決思路:根據后續的分析結果尋找對策。7.小結根據上述分析，我們可以看到：目前Mw接口上的切換失敗主要都是由于aSRVCC和bSRVCC兩種場景引起的。前者在更新算法后基本能夠得到解決，而后者目前可能解決的辦法不多，由此

17、造成的失敗可能會長期存在下去。另外，我們發現不論 Mw接口成功與否，均不影響 eMSC向MME發送正常的SRVCC PS to CS Complete消息。也就是說， Mw接口的結果只影響 SRVCC切換成功率，但不影響 SRVCC切換完成率。（二） Sv 接口從eSRVCC的信令流程圖來看，Sv接口涉及的信令交互相對較為復雜，要和局間的E接口（或局內的 A接口）共同完成 UE從4G向2G的切換。正常情況下，單純的 Sv接口 只有4條消息：消息塑型人12016-030710:12:68.6>GTP_MSG_SRVCCPS_TO_CS_RE 022016-03-0710:12:69.448

18、<GTP M8G SRVCC FS TO CS RSP32016-0307 10 ：13；00.008< GTP MSG S RVCC P S TO CS Ca M P NTF42016-03-07 10 13：00 C13GTP MSG SRVCCP S TO GS Ga M P ACK其中，第2條“ PS to CS Respons6'消息中有以下 2個重要的字段：cause字段：用于表示 PS到CS的SRVCC切換請求是否被接受。如果Cause的值不等于“ Request accepted',則表示切換被拒絕。srvcc-cause字段：如果 SRVCC Ca

19、use value 的取值不等于 “ Request accepted",通過該信元用于進一步表示用戶PS到CS的SRVCC切換請求被拒絕。3GPP協議29280-930協議對此字段定義了 110共10種取值，分別對應不同的失敗 原因。eSRVCC原因值英文解釋中文解釋1Unspecified未指定2Handover/Relocation cancelled by source system源系統取消切換或重分配3Handover /Relocation Failure with Target system目標系統切換或重分配失敗4Handover/Relocation Target

20、 not allowed不允許切換或重分配目標5Unknown Target ID未知目標ID6Target Cell not available目標單元不可用7No Radio Resources Available in Target Cell目標單元中沒有無線資源可用8Failure in Radio Interface Procedure無線接口流程失敗9Permanent session leg establishment error永久會話建立失敗10Temporary session leg establishment error臨時會話建立失敗另外，如果在 eMSC發出第3條S

21、RVCC PS to CS Complete消息前，收到了 MME發來的SRVCC PS to CS Cancel Notification消息，這條取消消息中也會包含 srvcc-cause字段。因此，對于Sv接口的分析，我們將重點基于 Response信息或Cancel消息的srvcc-cause 字段信息。（注：由于E接口和Sv接口共同構成了處理無線切換的信令管道”兩者有一定的重復性，且 E接口上更多的是與 eSRVCC無關的普通局間切換消息，因此目前暫時只 針對Sv接口進行分析。）1.自主開發Sv接口消息分析程序由于Sv接口上的 GTP消息很多，且無論切換是否成功，eMSC都會返回 P

22、S to CSResponse消息，只是通過其中的 cause字段、再結合srvcc-cause字段來區分不同的結果，因此僅根據消息類型根本無法看出是成功還是失敗。另外，就算找到了失敗的 Response消息，還要倒回去尋找對應的Request消息，才能找到切換的各種關鍵信息（用戶號、 STN_SR、目標小區等）。根據上述特點，人工分析顯然是無法勝任的，必須采用程序化手段進行自動化分析。為此，我們仔細對 GTP消息樣例分析了細致分析，確定了不同消息類型、不同關鍵信 息的特征代碼，設計了從原始GTP消息代碼流中定位失敗消息、并從對應Request消息中提取關鍵切換信息的處理思路。 然后在Micr

23、osoft Visual Basic平臺上，完成了 “ Sv接口消息 分析”程序的開發。在Windows7操作系統下，只要運行此程序，選中GTP接口消息文件，點擊“分析”按鈕，就可以迅速完成所有消息的讀取和分析，找出其中的失敗消息及失敗原因，并提取出本次失敗切換的發生日期、時間、 MSISDN、IMSI、STN_SR、目標小區，所有這些信息都 輸出到指定的文件中，以供進一步的深入分析使用。在這個分析程序的幫助下，我們可以迅速找出切換失敗的相關信息，大大提升了對Sv接口的分析效率，將可以節約出來的寶貴的人力資源投入到更有價值的優化工作中去。2. 失敗原因匯總從3月2日到3月7日我們連續在 CQG

24、S47上對Sv接口的GTP消息進行了持續跟蹤，并利用自主開發的分析程序對全量消息進行了匯總分析。匯總結果如下（切換請求次數=3992)eSRVCC原因值英文解釋中文解釋發生次數失敗率1Unspecified未指定110327.63%2Handover/Relocation cancelled by sourcesystem源系統取消切換或重分配2075.19%3Handover /Relocation Failure with Targetsystem目標系統切換或重分配失敗210.53%4Handover/Relocation Target not allowed不允許切換或重分配目標00.

25、00%5Unknown Target ID未知目標ID00.00%6Target Cell not available目標單元不可用00.00%7No Radio Resources Available in Target Cell目標單元中沒有無線資源可用60.15%8Failure in Radio Interface Procedure無線接口流程失敗40.10%9Permanent session leg establishment error永久會話建立失敗00.00%10Temporary session leg establishment error臨時會話建立失敗00.00%從

26、上表可見，10種srvcc-cause中，目前共出現了 1、2、3、7、8五種cause,其余5種沒有出現過。其中srvcc-cause=1、2出現的次數最多，構成了 Sv 口失敗的主要原因。為此，我們結合VoLTE信令監測系統、貝爾IMS鏡像消息，對以上5種cause依次進行了詳細分析。3. srvcc-cause=1 未指定）出現srvcc-cause=1的情況非常多，是本次分析的重點。利用Sv接口分析程序， 我們提取了所有與之相關的用戶號碼、STN_SR等信息。通過對比發現，這些失敗切換的STN_SR都不是重慶本地 STN_SR( 13746832/13746833 )。再對比對應的 用

27、戶號碼，發現存在 2種不同的失敗場景：a. 失敗場景1：用戶號碼也不是重慶號段，且以浙江、北京、福建等省的號段居多。聯想到春節期間發現的部分外省用戶在重慶進行eSRVCC切換失敗的案例，可以認定srvcc-cause=1就是相同的情況。具體場景如下：當采用華為scc as設備省份的volte用戶漫游至重慶發起注冊時，由 于貝爾IMS核心網設備會把自身內部的IP地址都加入到注冊消息的Via字段中，最終導致Via字段長度超過1024字節，超出了歸屬省華為 SCC AS 的處理限制。因此SCC AS處理本次注冊失敗，這就導致華為 SCC AS無法刷新MME 上保存的STN_SR號碼。因此，MME上保

28、存的仍然是之前的舊 STN_SR 而不是用戶當前注冊的重慶 SBC/ATCF對應的STN_SR。這樣，當用戶發起 eSRVCC時，MME發給eMSC還是舊STN_SR，顯然無法路由到當前的重慶 SBC/ATCF上，因此切換必然失敗。b. 失敗場景2:用戶號碼屬于是重慶號段(出現的概率較小)。具體場景如下：重慶volte用戶原先在外省注冊，后返回重慶，附著在重慶的mme上。重慶MME沒有選擇重慶本地 PGW，而是仍然選擇外省 PGW。根據VoLTE 附著和注冊流程，該用戶將向外省SBC/ATCF發起注冊。注冊完成后，外省 SBC/ATCF對應的STN_SR將刷新到重慶 MME上保 存。這樣，當用

29、戶發起 eSRVCC時，重慶MME發給重慶eMSC的將是外省的STN_SR。按照集團公司目前的切換流程規范，eMSC是無法通過長途SSA最終路由到外省SBC/ATCF的，因此切換將會失敗。c.失敗原因：2種場景下，eMSC都無法路由到當前的注冊SBC/ATCF，導致eMSC向目標MSC發出BICC_REL消息，提前終止了無線切換流程。對SRVCC切換完成率的影響：由于eMSC下發了異常的 SRVCC PS to CSResponse,因此將會影響 SRVCC切換完成率。對SRVCC切換成功率的影響：由于eMSC沒有下發 SRVCC PS to CSComplete，因此將會影響 SRVCC切換

30、成功率。d.解決思路：1） 場景1：此場景屬于外省華為 SCC AS與重慶貝爾IMS設備的配合問題， 前期我們已將此問題發至集團公司進行判責。3月3日集團公司已反饋判責結果，要求華為 SCC AS進行整改。預計此問題得到解決后，重慶的 eSRVCC切換成功率指標將有大幅提升，同時極大改善外省漫入VoLTE用戶的使用感知。2） 場景2：此場景屬于EPC附著時MME對PGW的選擇機制問題（目前已知愛立信MME存在這種情況，華為MME不存在）。解決思路也有2種：a）愛立信MME修改選擇機制。改為始終選擇重慶本地 PGW，這樣UE 就不會注冊到外省 SBC/ATCF上。b）完善目前的切換流程規范。在各

31、省的SSA上制作本省STN_SR的字冠分析數據，落地到本省的eMSC上。這樣對于外省的STN_SR，也 可以通過本省 eMSC-本省SSA-外省SSA-外省eMSC-外省ATCF的 路由找到當前 ATCF。同時，還需補充統計算法，將此場景下eMSC收到SSA返回的BICC_ANM 視同收到SIP_200消息，記作一次切換 成功。4. srvcc-cause=2（取消切換）除去前面分析的 srvcc-cause=1的情況以外，srvcc-cause=2 （取消切換）是 Sv口最多的失敗原因，影響eSRVCC切換成功率5%左右。a. 失敗場景:srvcc-cause=2發生時，都是 eMSC發出&

32、quot;PS to CS ResponsW'消息后，隨后又 收到 MME 發來的 SRVCC PS to CS Cancel Notification 消息。192016-03-07 10:17:19.532>GTF MSG SRVC C PS TO CS REQ202016-03-07 10:17:20.017GTP MSG SRVCC PS TO CS RSP212016-03-07 10:17:21 1282-GTP_M SG_SRVGC_PS,TO cs_cance l,ntfE22016-03-07 10:17:21 133<QTP MSG SRVCC P3 T

33、0 CS CANCEL ACKb. 失敗原因：對比正常的切換流程， 當UE成功接入到目標2G小區時，目標BSC會通過目標MSC通知源側的eMSC，eMSC收到后就會下發 SRVCC PS to CS Complete。在 srvcc-cause=2的場景下，eMSC并未收到目標側發來的UE接入2G成功的消息，而是收到 MME發來的SRVCC PS to CS Cancel Notification 消息，表明 UE應該是 在沒有成功接入目標 2G小區。對SRVCC切換完成率的影響：由于eMSC下發了正常的 SRVCC PS to CS Response,因此不會影響 SRVCC切換完成率。對S

34、RVCC切換成功率的影響：由于eMSC沒有下發 SRVCC PS to CSComplete，因此將影響SRVCC切換成功率。c. 解決思路：根據前面的分析，需要無線專業進一步分析UE未成功接入目標2G小區、同時取消切換的原因。5. srvcc-cause=3（目標小區切換失敗）srvcc-cause=3 （目標小區切換失敗）出現的概率較小，對eSRVCC切換成功率 的影響在1%以下。a. 失敗場景：對于這種無線切換失敗的場景，我們利用Sv接口分析程序，獲取到相關的目標小區；同時，根據程序獲取的切換用戶號碼、切換時間等信息，在貝爾IMS系統的接口鏡像消息包中提取到用戶呼叫時所在的4G小區信息，

35、一并發給 volte聯合辦公組的網優同事進行分析。網優同事初步分析后反饋，懷疑是在4G小區上定義了錯誤的相鄰 2G小區信息，導致了切換最終失敗。b. 失敗原因：懷疑是在4G小區上定義了錯誤的相鄰2G小區信息，導致了切換最終失敗。對SRVCC切換完成率的影響：由于eMSC下發了異常的 SRVCC PS to CS Response,因此將會影響 SRVCC切換完成率。對SRVCC切換成功率的影響：由于eMSC沒有下發 SRVCC PS to CSComplete，因此將會影響 SRVCC切換成功率。c. 解決思路：目前網優部門正在全網進行清查，排查此類定義了錯誤相鄰 2G小區信息的情況。6. s

36、rvcc-cause=7（目標小區資源不可用）srvcc-cause=7 （目標小區資源不可用）出現的概率也較小，對eSRVCC切換成功率的影響在1%以下。a. 失敗場景：從cause的解釋可以看出，是由于目標小區的無線資源不足，導致UE無法接入目標小區，導致無線切換失敗。b. 失敗原因: 目標小區的無線資源不足，導致切換失敗。對SRVCC切換完成率的影響：由于eMSC下發了異常的 SRVCC PS to CS Response,因此將會影響 SRVCC切換完成率。對SRVCC切換成功率的影響：由于eMSC沒有下發 SRVCC PS to CSComplete，因此將會影響 SRVCC切換成功

37、率。c. 解決思路：對于這種目標小區資源不可用的場景，我們將獲取到相關的目標小區，發給volte聯合辦公組的網優同事進行分析和處理（如擴容等）。7. srvcc-cause=8（無線接口流程失敗）srvcc-cause=8 （無線接口流程失敗）出現的概率很小，對eSRVCC切換成功率的影響在0.5%以下。a. 失敗場景：此cause的解釋較為含糊，且出現的次數較少，故對此失敗暫未總結出很明確的場景。b. 失敗原因：暫未定位。對SRVCC切換完成率的影響：由于eMSC下發了異常的 SRVCC PS to CS Response,因此將會影響 SRVCC切換完成率。對SRVCC切換成功率的影響：由

38、于eMSC沒有下發 SRVCC PS to CSComplete，因此將會影響 SRVCC切換成功率。c. 解決思路：暫未定位。從以上對Sv 口各種主要失敗原因值的分析，我們可以看到：目前影響最大的是外省漫游入訪volte用戶的切換問題。此問題已明確了解決方案，待外省華為 see as改造后即可解決。影響其次的是 切換取消問題。此問題需要網優部門深入分析，定位切換被取消的原因并確定相應的對策。其余3種失敗場景占比較小， 待網優部門排查完相鄰小區的錯誤，同時保證2G小區資源充足，可將對指標的影響控制在可接受范圍內。另外，Sv 口的消息主要是完成 UE從4G到2G的無線切換，因此 Sv 口的消息與A接口的2G切換信息類似，而且兩者的失敗原因值也基本是相互一致的。下面將Sv 口和A接口切換消息進行類比:A接口切換消息Sv接口切換消息消息方向消息方向HANDOVER REQUIREDBSC-MSCGTP_MSG_SRVCC_PS_TO_CS_REQMME-eMSCHANDOVER COMMANDMSC-BSCGTP_MSG_SRVCC_PS_TO_CS_RSPeMSC-MMECLEAR COMMANDMSC-BSCGTP_MSG_SRVCC_PS