1、第1章VOLTE指標提取21.1【OMC指標提取與優化】21.2【路測指標提取】4第2章 各項指標分析思路52.1【時延】52.1.1 TOP時延分析52.2 【MOS分析】102.2.1 MOS關聯分析102.2.2弱MOS分析112.3 【esrvcc切換】122.3.1 esrvcc分析思路122.3.2 esrvcc切換分析14第3章 相關案例153.1 【呼叫建立時延】153.1.1愛立信EPC強制鑒權加密導致volte呼叫延時增加案例案例153.1.2中興EPC開啟PS尋呼精細化配置導致VOLTE呼叫時延增加案例163.2 【esrvcc切換】173.2.1諾西參數配置導致ESRV

2、CC失敗案例173.2.2因終端模式設置無法觸發eSRVCC切換213.2.3 eMSC 給華為MME 返回“Unassigned Number”或“No Resources Available”223.2.4 eSRVCC切換時用戶聽到號碼不存在提示音223.2.5 eMSC因IMS網絡呼叫未響應重復發送Update233.2.6 eSRVCC切換后主被叫均聽不到對方的聲音233.2.7 MME 選擇eMSC機制影響測試效率24第1章VOLTE指標提取Volte指標的分析能夠高效發現影響用戶感知的質量問題，指標分為語音接入性、保持性、SRVCC、語音質量4個方面，即接通率、時延、掉話率、切換

3、成功率、MOS值等。1.1 【OMC指標提取與優化】目前LTEOMC無法直接提取VOLTE相關指標，需要分別提取后通過公式進行計算得到，比如eSRVCC切換成功率=（LTE到GSM的SRVCC切換出執行成功次數+ LTE到UTRAN的SRVCC切換出執行成功次數）/( LTE到GSM的SRVCC切換出準備請求次數+ LTE到UTRAN的SRVCC切換出準備請求次數),相對較復雜，故本手冊所有OMC指標均通過另外一個途徑-網優平臺提取。（1）登陸4A，準備進入網優平臺（2）進入網優平臺之后選擇數據查詢與維護-自定義查詢與模板創建，根據所要提取的指標（無線接通率、E-RAB掉線率、VOLTE用戶切

4、換成功率、esrvcc切換成功率、volte下行平均時延等）建立一個模板，本次將模板命名為Volte指標-xiaoyuan，后期如需要查詢volte指標將不再重復建立模板，直接進入第3步查詢模板。（3）數據查詢與維護按模板查詢與模板管理volte指標-xiaoyuan，然后選擇網元，時間粒度，直接導出表格。（4）本模板按照小區粒度來提取指標，方便查看TOP劣化小區，在使用本模板之前，建議先通過全網整體指標查看是否有大的網絡異常，如下圖：（5）將提取的表格打開，各項指標劣化排序，再逐個進行分析，目前VOLTE用戶數量群極少，基本是測試卡產生的業務，提取的孝感1月1日-6日的volte指標發現絕大

5、部分小區并無業務，另外極少部分產生業務小區并無指標劣化情況。（6）若存在劣化小區，優化思路為告警-干擾-C類（鄰區設置等）-B類（互操作等）-A類（QCI等各個參數）-隱性故障1.2【路測指標提取】目前按照集團規范以中國移動自動路測管理平臺提取的路測指標為準，測試指標商用標準為：KPI 商用初期 成熟期 接通率（%） 95% 97% 掉話率（%） 2% 1% 呼叫建立時延(s) 5 4 MOS3.0以上占比 80% 85%IMS注冊成功率（%） 97%98% eSRVCC成功率（%） 95% 97% eSRVCC切換時延-用戶面（ms） 400 350 （1）進入平臺，了解測試計劃，孝感的盒子

6、號為01027433 ，選擇測試計劃管理里對應的地市和號碼。（2） 選擇統計分析多維度基礎統計添加，開始根據需要進行統計。（3）得出最終的指標，可導出表格第2章 各項指標分析思路2.1【時延】2.1.1 TOP時延分析（1）選擇12月1日到12月4日，孝感其他日常測試的VOLTE，在文件列表中共計有8條數據。（2）選擇網格3的幾個log，進行VOLTE時延分析。（3）生成VOLTE時延信息彈框如下(4)按照呼叫建立時延進行排序，即可分析TOP。發現如下標紅的為時延較長的，基本上都是在節點3-4的時候時長過長，還有1個是節點2-3的時候時長過長。然后需要逐條對時長偏長的進行信令流程的查看，為了方

7、便起見，以下按照順序命名為TOP1，2,3,4,5。(5)本次將節點1-2,2-3,3-4的信令流程都進行查看、理清，后續工作中就是碰到哪個節點時長大就針對性分析哪個節點。節點1-2時長(無線資源配置的完成)節點2-3時長（QCI=1專用資源的建立）節點3-4時長（IMS網絡的交互）(6)首先對TOP1進行深度回放，查看對應信令流程。節點1-2（正常）：從主叫初始發invite到主叫初始接入RRC重配完成，大約100多ms。流程為主叫發起INVITE,但為空閑態，需要先建立信令連接，向eNodeB發起RRC Connection Request，eNodeB向UE回復RRC Connectio

8、n Setup，UE向eNodeB回復RRC Connection Setup Complete，確認RRC建立成功完成。eNodeB發送eNodeB UE S1AP ID，TAI，UE安全能力和安全密鑰等信息到MME，MME側用戶面承載建立成功后向eNodeB返回Complete，最后eNodeB向UE發送RRC Connection Reconfiguration消息，UE向eNodeB返回RRC Connection Reconfiguration Complete消息，確認無線資源配置完成。節點2-3（時延偏長）：從主叫初始接入RRC重配完成到主叫收到LTE NAS-Activate

9、dedicated EPS bearer CR，大約小于200多ms，TOP1該節點時延過長。分析：QCI=1的建立以及流程圖。正常該節點流程：主叫完成在EPC側的注冊以及IMS的注冊（QCI5承載）后，核心網會發起QCI1的承載建立，如下圖直接在主叫接入RRC重配完成后，接下來ENODEB向MME發送消息的時候中間多出了3600m。主叫UE發起呼叫時查看正好SINR值為-3dB，屬于在質差點起呼，起呼后還未來得及收到eNODEB發送含有鄰區信息的RRC Connection Reconfiguration消息，終端已經失步，失步后發起了RRC的重建立消息。重建立至孝感和平街-PLH-1進行了

10、QCI=1的建立。由于此次通話存在一次由于無線環境惡化導致的RRC重建，因此呼叫較長。節點3-4（時延偏長）：從主叫收到Activate dedicated EPS bearer CR到收到180ringing，大約小于200多ms，該節點時延過長。正常該節點流程：AS服務器轉發INVITE到被叫，發送下行數據首先經過PDN網關到SGW網關。SGW發現被叫UE為IDLE模式，發送下行數據到UE和通知到MME，同時緩存數據。MME對被叫UE發起尋呼流程，被叫UE也會完成在MME以及IMS的注冊。被叫UE向AS服務器送呼叫處理中的應答消息100 Trying 。被叫UE向AS服務器送183 Ses

11、sion Progress消息，提示建立對話的進度信息。（此時被叫QCI1專用承載建立）AS服務器向主叫主叫UE轉送183 Session Progress消息，主叫UE了解到整個Session的建立進度消息。主叫UE向AS服務器回復臨時應答消息PRACK，表示收到183 Session Progress消息。AS服務器向被叫終端B轉送臨時應答消息PRACK ，終端B了解到主叫UE收到183 Session Progress消息。被叫終端B向AS服務器發送200 OK消息，表示183 Session Progress請求已經處理成功。AS服務器向主叫主叫UE轉送200 OK消息。主叫UE向AS

12、服務器發送UPDATE消息，意在與被叫終端B協商相關SDP信息。AS服務器向被叫終端B轉送UPDATE消息。被叫終端B向AS服務器發送200 OK消息，表示UPDATE請求已經處理成功。 14. AS服務器向主叫用戶A轉送200 OK消息，通知用戶A UPDATE請求已經處理成功。被叫UE振鈴，用戶振鈴后，向AS服務器發送180 Ringing 振鈴信息。 16. AS服務器向主叫主叫UE轉送180 Ringing 振鈴信息。分析：主叫UE完成Activate dedicated EPS bearer后，一直未收到被叫的尋呼響應，此時無線信號覆蓋良好，對比主被叫信令流程，發現被叫UE收到尋呼消

13、息滯后導致響應主叫UE在信令IMS_SIP_INVITE->Trying 100和IMS_SIP_INVITE 183之間時間較長，需要和核心網溝通，如下圖所示：2.2 【MOS分析】2.2.1 MOS關聯分析MOS評分是一個端到端的問題，經過的網元，接口特別多，因此任何一個語音傳輸環節的問題，都會導致語音損傷，最終使MOS分下降，需要逐個排查。本手冊只進行空口分析，對影響MOS的空口網絡問題分別闡述。2.2.1.1 覆蓋類網絡覆蓋不好，網絡中必然存在較多的接收質量差區域，影響話音質量。覆蓋優化：解決弱覆蓋路段，控制越區覆蓋和重疊覆蓋區。結合網格拉網測試數據和掃頻結果,重點解決“高電平質

14、差”的重疊覆蓋度高的路段 ，有效提升網絡結構。掃頻分析。使用掃頻儀測試網格后對掃頻中越區覆蓋小區進行覆蓋控制，對掃頻中沒有主覆蓋小區的區域進行調整天線。城區ATU分析。對網格進行大量測試，對路測中出現的問題路段進行分析解決，對所有的測試LOG分主被叫做拉線圖層并分析，找出過覆蓋小區進行調整天線，之后進行覆蓋驗證，保證覆蓋良好。2.2.1.2 干擾類干擾會導致超過基站解調能力無法識別無線幀，導致無線幀丟失，話音斷續。通過測試數據和MR數據分析，針對質差頻點，逐一進行合理優化并驗證，提升整體語音質量。 合理規劃PCI。相同PCI的復用距離要足夠遠，盡量避免站內或鄰區中配置PCIMOD3的值相同，保

15、留適量PCI用于室分規劃、位置邊界規劃和網絡的擴展等措施避免PCI設置不合理導致的高干擾。 外部干擾。此類因素只能通過協調溝通也來進一步改善。 2.2.1.3 切換引起的MOS問題由于LTE是硬切換，從源小區切換到目標小區，必然存在幀的丟失，因此通話過程中由于切換導致的語音斷續是不可避免的。因此需要檢查相關切換參數，盡量避免過多、過頻繁的切換。鄰區配置核查。鄰區配置不合理導致切換到質量差小區或者切換較慢，一旦不能夠及時把語音呼叫切換到更好鄰區，便會導致語音質量持續差，引起MOS分值低，需要刪除冗余鄰區、增加必要鄰區來優化。異頻門限調整。如果異頻測量開啟太早，會導致大量資源浪費在測量上，從而影響

16、速率；如果異頻測量開啟太晚，會導致部分區域無法及時切換，需要根據日常拉網測試數據進行分析，調整異頻門限至合理。備注：影響MOS值的因素還有很多，本手冊只就空口的幾個重要因素簡單說明。2.2.2弱MOS分析（1）同樣將時間、數據來源、業務類型等各項篩選項選擇完成，出現測試log。（1）選擇VOLTE的MOS分析，進行弱MOS分析。（3）選擇第一條log生成弱MOS分析條件設置信息彈框如下，選擇MOS<=3.0的設置條件：（4）呈現結果有4條弱MOS，其中2條持續弱MOS，2條弱MOS點，弱MOS點具有偶然性可以忽略，只進行持續弱MOS分析。 （5）接下來對第一條持續弱MOS結合現場環境與路

17、網通地圖進行分析，第一條有3個采樣點，對每個采樣點逐個查看。（6）采樣點1和2收孝感九真社區3小區信號，采樣點3收到北京二路3小區的信號，RSRP分別達到-111dBm，判定為無線環境差導致的弱MOS。2.3 【esrvcc切換】2.3.1 esrvcc分析思路VoLTE用戶的eSRVCC流程基于用戶已EPC附著、PDN建立和呼叫建立成功的基礎上，整個流程按順序分為幾個大階段：SRVCC切換的觸發、切換資源準備、切換執行和資源釋放。切換失敗的話，根據現象不同，可能需要抓取終端、eNB、MME、eMSC/MGW、HSS、SBC、I/S-CSCF和SCC AS網元的信令流程，查看接口消息，根據以下

18、關鍵環節進行分析定位，判斷發生異常（無響應、錯誤響應等）的環節和網元。2.3.1.1 無線網絡eNB的配置、eNB與UE之間是否交換切換相關信息檢查1：eNB的切換配置參數。檢查2：eNB是否下發切換指令，指示UE開始GSM鄰區測量。檢查3：UE是否上傳測量報告。檢查4：eNB根據測量報告和門限設置， 判決應觸發SRVCC切換，選定切換目標小區2.3.1.2 eNB在S1接口是否發起SRVCC切換請求消息至用戶所在的MME檢查1：eNB是否向MME發送S1切換請求消息（Handover Required），消息中的關鍵字段有：Handover Type、Target ID和SRVCC HO I

19、ndication。2.3.1.3 MME在Sv接口是否發送SRVCC 切換請求消息至正確的eMSC檢查1：MME中的相關數據配置：1) MME配置的eMSC Sv接口數據。2) 基于切換目標小區的LAI信息，LAI-eMSC對應關系的配置數據，MME本地配置或DNS查詢（DNS服務器配置）獲取對應的eMSC。3) 存在多個eMSC時，MME內部的輪選機制。檢查2：MME是否選擇正確的、工作狀態的eMSC發送出PS to CS Request消息，其中包括的關鍵字段有：C-MSISDN、STN-SR和Target Cell ID。2.3.1.4 eMSC向切換目標網絡申請無線資源預留是否成功、

20、是否返回給MME/eNB/UE 檢查1：eMSC是否基于切換目標小區信息向正確的目標網絡發起切換請求消息，若沒有則需檢查切換配置數據。檢查2：切換資源預留成功后、eMSC是否接收到切換響應，是否返回給MME、eNB和UE，最終UE是否成功接收到切換指令。2.3.1.5 eMSC是否向IMS網絡發起呼叫、是否接收到SIP 200 OK消息檢查1：eMSC是否基于接收到的STN-SR發起INVITE消息至SBC（ATCF/MGW）1) 若沒有，則需檢查eMSC中eSRVCC相關功能是否開啟、配置參數和至IMS網絡的IP連接，包括：eSRVCC、aSRVCC和mid-SRVCC的支持和功能的開啟、缺

21、省SAI、STN-SR與ATCF的映射、至IMS網絡的IP連接和路由狀態。2) 若發起，檢查SIP INVITE消息中Feature Caps頭域，是否包含aSRVCC、mid-SRVCC支持能力，若沒有則需檢查相關功能的支持能力、功能的開啟檢查2：ATCF是否按照注冊時記錄的用戶數據（C-MSISDN、ATU-STI），轉發呼叫至用戶歸屬的SCC AS消息檢查3：SCC AS是否返回SIP 200 OK。檢查4：若用戶呼叫狀態為alerting狀態，SCC AS是否發送INFO消息告知eMSC。若用戶呼叫狀態為mid狀態，SCC AS是否下發REFER消息給eMSC，eMSC是否立即發起第二

22、路呼叫，第二路呼叫是否抵達SCC AS。2.3.1.6 UE接入GSM網絡后，切換執行是否成功檢查1：UE是否成功接入GSM網絡、BSC是否發送HO complete消息至eMSC檢查2：eMSC是否發送切換完成消息（PS to CS HO Complete）至MME。檢查3： MME接收到來自eMSC的切換完成消息后，是否釋放切換用戶的所有資源。2.3.2 esrvcc切換分析（1）目前路測中esrvcc切換較少，現選取武漢江南片區12月份測試網格24的log進行esrvcc切換分析。（2）彈出esrvcc無線性能分析性能彈框如下，本次測試中該網格esrvcc沒有失敗（目前路網通平臺上沒有發

23、現esrvcc切換失敗的log），如果有失敗情況，下圖的“失敗現象及原因”會智能展現。（3）點擊某次esrvcc切換查看切換信令，下圖為esrvcc切換成功正常信令流程，如有切換失敗，可比對下圖逐一進行查看。第3章 相關案例3.1 【呼叫建立時延】3.1.1愛立信EPC強制鑒權加密導致volte呼叫延時增加案例案例原因定位問題描述：拉網測試中，愛立信EPC下掛區域的UE每次進行rrc連接過程中均需要進行鑒權加密，導致呼叫延遲比其它EPC區域增加。問題原因：經過分析信令流程，原因定位為愛立信EPC配置問題，分析流程如下：1、提取信令，左為愛立信EPC區域，中間為中興EPC區域，右為華為EPC區域

24、。2、從圖中可以發現，愛立信EPC區域比中興和華為EPC區域多出來了一次Authentication和一次Security的過程，該過程耗時約200ms。如果主被叫都需要進行鑒權加密，則volte總時延將增加400ms。3、與核心網進行討論，發現有特定終端在更換卡后，仍使用換卡前的GUTI接入網絡，在不對齊進行鑒權的情況下，會導致計費異常。因此華為、中興配置為附著強制鑒權，而愛立信MME由于不能區分業務流程鑒權，配置為每次必須鑒權（包含AttachTAUSR）。因此在此處會看到愛立信EPC每次均會下發鑒權加密要求。從而導致愛立信EPC下掛區域的UE每次進行rrc連接過程中均需要進行鑒權加密。影

25、響范圍： 愛立信EPC下掛區域內的volte時延指標。解決方案由于涉及到計費，核心網側暫時不能修改愛立信EPC配置，仍然要求UE每次rrc連接時強制鑒權加密。待愛立信EPC升級版本。3.1.2中興EPC開啟PS尋呼精細化配置導致VOLTE呼叫時延增加案例原因定位問題描述：中興 EPC開啟了 PS 尋呼精細化配置，首次尋呼時僅尋呼保存的 UE 最近注冊的 1+n(n<=6)個 eNodeB，二次尋呼時再針對 TA LIST 范圍進行尋呼，導致VOLTE 語音業務接續時延增加。問題原因： 針對TOP時延進行了分析：拉網過程中出現多次呼叫建立節點3-4時長過長問題，導致整個呼叫建立過程時延較長

26、。如下圖所示分析每次節點3-4信令過程，發現主叫UE完成Activate dedicated EPS bearer后，一直未收到被叫的尋呼響應。此時無線信號覆蓋良好，對比主被叫信令流程，發現被叫UE收到尋呼消息滯后導致主叫UE信令在IMS_SIP_INVITE->Trying 100和IMS_SIP_INVITE 183之間時間較長，如下圖所示通過協調中興EPC查詢得知，中興 EPC 為了減少信令負荷、降低尋呼壓力，開啟了 PS 尋呼精細化配置，首次尋呼時僅尋呼保存的 UE 最近注冊的 1+n(n<=6)個 eNodeB，二次尋呼時再針對 TA LIST 范圍進行尋呼，由于 VOL

27、TE 業務使用 PS 尋呼，因此也將遵循該原則。當 VOLTE 終端處于快速移動過程中，首次尋呼時其尋呼的 eNodeB 可能不是用戶當前所處的 eNodeB，導致需要針對用戶進行二次尋呼才能接通VOLTE 語音業務，引起VOLTE 語音業務接續時延增加。影響范圍：中興EPC下處于快速移動過程中的VOLTE終端的VOLTE呼叫時延。解決方案中興 EPC目前已具備將 VOLTE 業務尋呼與 PS 業務尋呼區分開的功能，通過設置軟參進行配置后，VOLTE 業務直接改用 TA LIST進行尋呼。測試區域VOLTE注冊時延修改前5.71修改后3.55備注通過設置軟參將VOLTE 業務尋呼與 PS 業務

28、尋呼區分開，存在的風險是增加尋呼負荷，進行設置時需同步參考尋呼負荷評估情況。3.2 【esrvcc切換】3.2.1諾西參數配置導致ESRVCC失敗案例原因定位問題描述：VOLTE開啟后，需要對eSRVCC功能進行驗證，開啟shiyanyidongdalou-NLH-2小區的eSRVCC功能及相關參數設置后進行驗證，發現有interRAT的measure report，但是無法切換至GSM網絡進行通話。問題原因： eSRVCC的基本信令流程如下：1. 對eSRVCC相關的功能型開關以及切換門限核查，基本沒有問題；2. 通過測試log可以知道UE已經上報了B2事件，根據信令可知，上報B2事件后，e

29、nodeb會向MME發送Handover Repuire消息，核心網側進行handover prepare procedure后，MME會向enodeb發送Handover Command，而后 UE 會進行4Gà2G的切換。無線側無法跟蹤S1AP的信令，遂使用CRT進行S1口信令跟蹤，跟蹤的情況如下：通過S1的信令可以看到enodeb上發了Handover Repuire消息，但是1s后又上發了一條Handover Cancel消息（Cancel的原因是：ts1relocpre-expiry），以致eSRVCC失敗；3. 很明顯是核心網側prepare超時導致eSRVCC失敗，再次

30、核查參數，發現tS1RelPrepG設置為1000ms，該參數的解釋是：Guard against failure of the MME to respond in preparation phase of S1 handover to GSM，Timer TS1RELOCprep_InterRAT is used to guard against failure of the MME to respond preparation phase of S1 handover to another 3GPP RAT. It is started in the source eNB when the

31、 S1AP: HANDOVER REQUIRED message is sent to the MME and is stopped when the S1AP: HANDOVER COMMAND or S1AP: PREPARATION FAILURE message is received in response. If the timer expires the handover is aborted or cancelled.即該定時器是enodeb發送HANDOVER REQUIRED message后，等待MME 回復HANDOVER COMMAND的保護時長，如果超時，此次Han

32、dover就會Cancel，導致eSRVCC失敗。影響范圍：所有基站ESRVCC成功率很低。解決方案1. 將tS1RelPrepG由1000ms修改至最大的5000ms后，eSRVCC測試正常， Uu口信令：S1口信令Handover command：備注對于新功能（如VOLTE、eSRVCC等）由于參數設置較多，具體判斷是哪個參數設置導致的問題不太容易，可以通過測試和信令跟蹤來反推參數的問題。跟蹤S1口的信令發現，正常的prepare的時間約1.74s，建議將tS1RelPrepG參數設置到3s以上，來保證Handover Prepare的成功。3.2.2因終端模式設置無法觸發eSRVCC切

33、換【問題現象】無法發起eSRVCC切換。【原因定位】用戶消息跟蹤時發現，用戶注冊時1、SCC AS未發送MESSAGE消息給ATCF2、檢 查SCC AS 到HSS 取ueSrvccCapData 數據流程， HSS 返回<UE-SRVCC-Capability>0</UE-SRVCC-Capability>。3、查詢HSS中的用戶動態數據（LST DYNSUB: IMSI="460025343017119"），返回UE-SRVCC-Capability = UE-SRVCC-NOT-SUPPORTED。定位為終端未攜帶SRV CC能力標識導致。查看

34、終端設置果然為4G only，確定。【解決方案】終端上設置為2/3/4G模式后，終端上報SRVCC能力，問題解決。3.2.3 eMSC 給華為MME 返回“Unassigned Number”或“No Resources Available”【問題現象】華為MME將切換請求發給eMSC后，eMSC返回“unassigned number”（或“no resourcesavailable”）的失敗原因碼，導致切換失敗。【原因定位】1、MME從HSS處接收的STN-SR為：8613449924。2、而MME發給eMSC（SRVCC IWF）的SRVCC PS to CS Request消息中攜帶的

35、STN-SR為： 198613449924。3、eMSC（SRVCC IWF）不識別該格式的STN-SR號碼，返回“unassigned number”（或“no resources available”）的失敗原因碼，導致切換失敗。4、MME為何要在STN-SR前加上19前綴送給eMSC？查找3GPP規范可知：3GPP TS 29.280協議中定義了MME發往eMSC的“SRVCC PS to CS Request”消息的相關信元結構，因為協議版本差異，不同版本中對STN-SR號碼的格式定義前后有區別，兩邊網元遵循協議版本不一致，導致此問題發生。5、當前華為MME側改造方案中，Sv接口使用2

36、9280 R10版本協議格式對接，而eMSC側默認支持R8版本協議格式（遵循前期浙江外場測試配置）。查詢華為MME數據配置，確實在STN-SR號碼攜帶了NANPI字段19。【解決方案】若VOLTE工程建設中遇到此問題，eMSC可與MME側共同協商，一方做修改適配即可。1、 華為MME，可修改GTPCV2CMPT不攜帶NANPI字段（此配置為全局配置，無法針對具體eMSC設置）2、 華為eMSC，可修改GTPPE中GTP對端實體能力列表，適配支持R10版本協議STN-SR格式。（可支持針對具體MME設置）3、 根據調研各廠家MME、eMSC實現，最終按照集團要求MME和eMSC針對STN-SR信

37、元結構都按照3GPP TS 29.280 R10版本來處理。3.2.4 eSRVCC切換時用戶聽到號碼不存在提示音【問題現象】VoLTE主叫用戶A呼叫VoLTE用戶B，A在呼叫過程中發生eSRVCC切換，切換失敗，且用戶聽到“號碼不存在”的提示音。【原因定位】eMSC上進行消息跟蹤，發現1、在用戶A 發生eSRVCC 切換時， eMSC 向GS 發起MAP_PREPARE_HANDOVER_REQ，并收到了GS的確認消息。在此之后eMSC向GS發起媒體更新的INVITE，所以并非該原因引起，原因排除。2、eMSC在向MME發送PS_TO_CS_RSP消息指示MME切換后，并未發送INVITE消

38、息到ATCF。3、eMSC上使用LST CNACLD查詢，發現STN-SR路由指向了GS，指向有誤，故聽號碼不存在提示，應該修改STN-SR的路由指向為ATCF。【解決方案】eMSC上修改STN-SR路由指向ATCF問題解決。3.2.5 eMSC因IMS網絡呼叫未響應重復發送Update【問題現象】因eSRVCC切換eMSC發起IMS呼叫請求至IMS，未收到響應，eMSC重復發送UPDATE，切換失敗。【原因定位】1、 IMS側不支持Precondition功能。2、檢查eMSC和IMS域（S-CSCF）之間的SIP中繼是否啟用了Precondition功能。按照協議IETF RFC 3312

39、，S-CSCF返回的183消息的Require頭域攜帶“precondition”，則eMSC會認為S-CSCF支持Precondition功能。但此183消息中未攜帶Precondition相關的QoS參數，因此后續eMSC發起UPDATE協商，但S-CSCF沒有正常回復200 OK，導致eMSC重復發送UPDATE。183消息如下所示:SIP/2.0 183 Session Progress.Require: 100rel,precondition3、在MSOFTX3000上使用LST SIPTG檢查EMSC和S-CSCF的SIP中繼數據配置，其參數“是否支持Precondition”為“YES（是）”原因找到，eMSC和IMS域（S-CSCF）之間的SIP中繼啟用了Precondition功能但IMS側不支持導致。【解決方案】使用MOD SIPTG修改SIP中繼數據配置Precondition為否。MOD SIPTG: TGN="emsc-scscf", SUPPRECONDITION=NO。3.2.6 eSRVCC切換后主被叫均聽不到對方的聲音【問題現象】VoLTE主叫在通話在呼叫過程中發生eSRVCC切換，切換成功