1、VoLTE經(jīng)驗總結(jié)1 廣州VOLTE網(wǎng)絡(luò)質(zhì)量現(xiàn)狀經(jīng)過近三個月的優(yōu)化工作，廣州ATU網(wǎng)格內(nèi)，掉話率逐步改善，從11.5%（四月）下降至3.27%（七月）；接通率從93.1%提升至6月份的96.6%，七月份下降至89.46%。七月份測試期間核心網(wǎng)的IOT測試也在進行；較多invite 500、SIP unknown、MT CSFB等異常問題導(dǎo)致的連續(xù)多次未接通。廣東公司計劃在本周對廣州IMS進行華為IMS替換愛立信IMS的操作，故七月份測試遇到的異常IMS相關(guān)問題分析進度暫緩。2 廣州VoLTE測試問題優(yōu)化進展2.1 異頻重定向掉話問題驗證（問題解決）背景：中興eNodeB在P01版本下，因鄰區(qū)缺

2、失導(dǎo)致異頻重定向掉話，該問題需升級P02版本解決。網(wǎng)格44、45測試過程中未發(fā)生異頻重定向掉話，信令上分析測試過程中出現(xiàn)過多次連續(xù)上報異頻A3的測報，未切換也未發(fā)生重定向，P02版本禁止QCI 1 業(yè)務(wù)異頻重定向功能生效。2.2 異系統(tǒng)重定向掉話問題驗證（問題解決）背景：中興eNodeB在P01版本下，VoLTE發(fā)生重定向掉話，該問題需升級P02版本解決。網(wǎng)格44、45基礎(chǔ)覆蓋較差，以往拉網(wǎng)測試均會發(fā)生多次系統(tǒng)重定向掉話，7月24日，網(wǎng)格44、45完成P02版本升級，升級后重定向掉話問題解決，拉網(wǎng)測試掉話率改善明顯。P02版本禁止QCI 1業(yè)務(wù)重定向功能打開，終端上報A2（盲重定向門限）或B2

3、事件（2G鄰區(qū)信息錯誤）等前期會導(dǎo)致重定向的情況下，網(wǎng)絡(luò)均未下發(fā)重定向，VoLTE業(yè)務(wù)保持通話結(jié)束后自動掛機，未產(chǎn)生掉話事件2.3 TM3/8轉(zhuǎn)換掉話問題驗證（問題解決）背景：中興eNodeB在P01版本下，VoLTE業(yè)務(wù)過程中發(fā)生TM3到TM8模式轉(zhuǎn)換，因為基站提前轉(zhuǎn)換導(dǎo)致終端掉話，該問題需升級P02版本解決。8月3日，網(wǎng)格45所有升級站點打開TM3/8自適應(yīng)，驗證VoLTE業(yè)務(wù)在TM3與TM8進行轉(zhuǎn)換時是否掉話，測試結(jié)果如下：網(wǎng)格45遍歷拉網(wǎng)測試中出現(xiàn)26次TM3向TM8的模式轉(zhuǎn)換，轉(zhuǎn)換正常未發(fā)生異常。2.4 X2開啟告警驗證（問題解決）背景：廣州前期因中興網(wǎng)管告警問題未打開X2接口，導(dǎo)致

4、跨站重建立不可用，需升級P02版本對X2告警量進行抑制。8月5日，網(wǎng)格44、45所有升級站點打開X2接口功能，指定開啟X2自配置站點213個，8月6日統(tǒng)計站點X2偶聯(lián)條數(shù)共計4604條。告警問題：網(wǎng)格44、45開啟X2后，8月6日網(wǎng)管出現(xiàn)60多條X2斷鏈告警，告警主要原因：a、傳輸不通，部分微站無法與宏站正常建鏈；b、個別小區(qū)被蔽塞不能正常建鏈；升級后EMS網(wǎng)管上只出X2斷鏈告警，并且所有基站僅出1條（多條X2斷鏈），無SCTP斷鏈告警，網(wǎng)管上可明確區(qū)分X2與S1告警，告警量大幅下降。2.5 X2開啟跨站重建立功能驗證P02版本支持無鄰區(qū)的跨站重建立，在X2鏈路建立后，對于無鄰區(qū)跨站重建立帶來

5、一定的增益，提高跨站重建立的效率；X2開啟,網(wǎng)格44統(tǒng)計VoLTE拉網(wǎng)發(fā)生重建立請求共14次,跨站重建成功6次；從性能指標統(tǒng)計來看，RRC重建成功率從50%左右提升至80%左右。原理：目標小區(qū)通過終端上報的PCI查找該站點保存的有X2關(guān)系的鄰站所有小區(qū)信息，向所有相同PCI小區(qū)索取上下文。3 廣州VOLTE優(yōu)化經(jīng)驗3.1 日常優(yōu)化工作日常優(yōu)化工作主要從無線覆蓋優(yōu)化、參數(shù)優(yōu)化、系統(tǒng)內(nèi)外鄰區(qū)優(yōu)化，功能優(yōu)化四個方面著手，與ATU路網(wǎng)、工程建設(shè)緊密配合，提升整體網(wǎng)絡(luò)質(zhì)量。3.2 RLC優(yōu)先級優(yōu)化現(xiàn)象：呼叫建立與切換過程沖突，專載被MME釋放。呼叫建立過程中專載建立與切換幾乎同時發(fā)生，MME未收到NAS

6、專載完成消息導(dǎo)致釋放專載，終端回復(fù)invite580（也有上發(fā)CANCLE的情況），專載丟失形成未接通事件。原因分析：QCI5設(shè)置的RLC優(yōu)先級為2，高于SRB=2(傳送NAS層消息)配置為3. 導(dǎo)致NAS的層3消息已經(jīng)比MR要早，但是因為優(yōu)先級比MR和SIP低，未及時發(fā)送。優(yōu)化措施：降低QCI 5優(yōu)先級，確保SIP消息及時上傳，修改后此類問題改善明顯。3.3 QCI 5 PDCP DiscardTimer時長優(yōu)化現(xiàn)象：終端業(yè)務(wù)建立過程中，出現(xiàn)SIP信息傳遞丟失的問題，導(dǎo)致收到網(wǎng)絡(luò)下發(fā)的INVITE500或者580等原因值釋放。原因分析：UE在無線信道較差的情況下，SIP信令發(fā)送或接收不完整或

7、者無法及時傳遞，導(dǎo)致IMS相關(guān)定時器超時而發(fā)起會話cancel。經(jīng)過分析，由于QCI5的pdcp 丟棄時長過小，在無線覆蓋較差的地方，上行時延會變大，容易導(dǎo)致QCI5信令丟包。優(yōu)化措施：QCI5 PDCP DiscardTimer由300ms修改為無窮大優(yōu)化效果：VoLTE無線接通率提升明顯3.4 SBC傳輸協(xié)議TCP重傳次數(shù)優(yōu)化背景：被叫從2G返回4G后，主叫起呼，被叫首先bye消息，緊接著接連收到多條上一次呼叫的invite，被叫回復(fù)bye481invite486invite580，呼叫失敗。優(yōu)化措施：愛立信SBC對TCP配置進行了修改：最大重傳次數(shù)從15次改為5次，最大重傳隔間從十幾分鐘

8、改為15s，此類問題已解決。3.5 系統(tǒng)間鄰區(qū)優(yōu)化廣州LTE網(wǎng)絡(luò)的GSM鄰區(qū)關(guān)系根據(jù)工程參數(shù)、共站2G鄰區(qū)同向小區(qū)繼承進行規(guī)劃，同時根據(jù)4G、2G道路測試數(shù)據(jù)匹配進行鄰區(qū)補充：4G弱信號路段與2G拉網(wǎng)服務(wù)小區(qū)匹配：利用第三方拉網(wǎng)測試數(shù)據(jù)，將4G和2G拉網(wǎng)信號強度、經(jīng)緯度、服務(wù)小區(qū)等信息導(dǎo)出。通過經(jīng)緯將4G弱信號(RSRP-95dbm）在50米范圍內(nèi)擬合，根據(jù)擬合度對2G鄰區(qū)進行補漏工作5月份第一輪擬合數(shù)據(jù)，剔除現(xiàn)網(wǎng)已配置的鄰區(qū)關(guān)系，補漏483對；6月份第二輪擬合數(shù)據(jù)，剔除現(xiàn)網(wǎng)已配置的鄰區(qū)關(guān)系，補漏鄰區(qū)關(guān)系487對。eSRVCC切換提升明顯，且由于2G鄰區(qū)不準確導(dǎo)致的異系統(tǒng)重定向大大減少。3.6

9、 重定向掉話中興區(qū)域掉話最嚴重屬于重定向掉話，在中興基站算法中，以下三種可能發(fā)生重定向，重定向釋放RRC后，專載同時被拆除，VoLTE業(yè)務(wù)產(chǎn)生掉話。3.7 上行PUSCH功控參數(shù)優(yōu)化背景：4月集團在中興區(qū)域拉網(wǎng)測試發(fā)現(xiàn)上行PUSCH發(fā)射功率偏高，對現(xiàn)網(wǎng)參數(shù)檢查發(fā)現(xiàn)，中興區(qū)域上行期望功率值設(shè)置過高。優(yōu)化措施： 進行功控相關(guān)參數(shù)優(yōu)化，現(xiàn)網(wǎng)配置： p0NominalPUSCH =-75 ；puschPCAdjType=0優(yōu)化值： p0NominalPUSCH =-87 ；puschPCAdjType=2同等路損情況下，參數(shù)修改后，ue發(fā)射功率大約下降23dB。目前終端平均上行發(fā)射功率仍高于10db，

10、仍需中興完善現(xiàn)有功控方式。修改后，PUSCH TxPower（10dbm以上）占比由40%下降到30%左右。3.8 RTP丟包率優(yōu)化背景：4月份測試中，中興區(qū)域RTP丟包率偏高，個別網(wǎng)格甚至達到2%以上。原因分析：在無線質(zhì)量較好的情況下基本無丟包；無線質(zhì)量較差的情況下上行丟包現(xiàn)象較為嚴重，PDCP重傳時間超時，數(shù)據(jù)包將被丟棄；外場測試表明QCI 1 PDCP Discardtimer 配置與RTP丟包率及Jitter有密切關(guān)系，QCI 1 PDCP Discardtimer 配置越大，RTP丟包率越低，但Jitter也隨之變大。MOS值與RTP丟包及Jitter關(guān)系都較大，目前廣州正在601P

11、02版本下進行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的對比驗證。進一步聯(lián)合中興公司定位RTP丟包率偏高的問題，并推動產(chǎn)品功能算法改進。3.9 MME專載保存功能（可選）功能描述：在基站發(fā)起UE-lost原因值的上下文釋放請求時，MME保持專載2s不釋放，等待空口重建。驗證情況：已在GZMME1602下成功驗證了該功能。當時無線環(huán)境較差，UE發(fā)起RRC重建失敗，通過MME專載QCI1保持功能使得在新發(fā)起的業(yè)務(wù)過程中，RRC重配中建立包括專載QCI1的3條DRB，不會發(fā)生掉話。（本次測試中專載保持時長約1.358s）功能總結(jié)：1）當無

12、線環(huán)境較差時，UE發(fā)生RRC重建，若RRC重建成功，手機將不會掉話。2）MME側(cè)也可以在RRC重建失敗后，通過MME專載QCI1保持功能使得在新發(fā)起的業(yè)務(wù)過程中，專載QCI1繼續(xù)保持，也可使得手機不掉話。3）此功能為愛立信MME非必選功能，建議打開。但是該功能不在集采目錄，暫時無法采購。3.10 專載釋放與切換沖突，通話結(jié)束未收到專載釋放掉話問題描述：在拉網(wǎng)測試過程中，通話掛機后，主叫上報BYE消息，IMS回BYE200消息前后，同時手機發(fā)生切換，未收到EPS專載釋放請求，1s后軟件統(tǒng)計掉話。問題分析：經(jīng)分析MME log，發(fā)現(xiàn)MME未收到PGW下發(fā)的delete bearer request

13、消息。當X2切換觸發(fā)SGW-initiated bearer modification procedure（完整信令是CCR-CCA），如果此時SIP掛機觸發(fā)PCRF也發(fā)RAR給PGW，由于Gx鏈路時延等原因，使得RAR先于CCA到達PGW，根據(jù)協(xié)議規(guī)定，PGW會繼續(xù)SGW-initiated bearer modification procedure而reject RAR (result code DIAMETER_OUT_OF_SPACE)。優(yōu)化措施：當前解決辦法：（1）縮短DRA時延配置。（2）修改SAPC到DRA鏈路為主-備模式，保證CCA和RAR走同一路徑和到達PGW的先后順序。優(yōu)化

14、結(jié)果：近期調(diào)整后的網(wǎng)格測試，暫時沒有發(fā)現(xiàn)BYE200消息前后發(fā)生的切換沒釋放QCI 1專載的情況。3.11 通話結(jié)束MME收到del bearer req，專載釋放與切換沖突，基站未下發(fā)NAS問題描述：通話掛機后，主叫上報BYE消息，IMS回BYE200消息前后，同時手機發(fā)生切換，EPS專載沒有釋放，1s后軟件統(tǒng)計掉話。問題分析：主叫掛機后，MME收到del bearer req，下發(fā)Deactivate EPS bearer context Request給源eNB攜帶NAS釋放專載，但同時源eNB觸發(fā)X2切換，向MME響應(yīng)ERAB release response （X2-Handover

15、-Triggered），NAS消息未下發(fā)到手機。根據(jù)協(xié)議36.413 中8.6.2.4有描述當eNB在觸發(fā)X2切換時，eNB將不傳遞NAS消息。優(yōu)化措施：屬測試軟件統(tǒng)計問題，建議軟件加以剔除該問題。4 存在問題和建議設(shè)備功能問題：切換沖突問題：基站無法解碼SIP消息，UE專載建立完成的NAS消息上報時間無法確認，基站側(cè)難以徹底解決，需要核心網(wǎng)做相應(yīng)的功能優(yōu)化，呼叫過程eSRVCC：IMS不支持呼叫過程中發(fā)生eSRVCC，在4g網(wǎng)絡(luò)覆蓋達到2g規(guī)模之前，該問題都不可避免存在。終端eSRVCC測量性能提升4G弱覆蓋比例較高：廣州網(wǎng)格范圍內(nèi)黑點路段603個，是VoLITE業(yè)務(wù)問題多發(fā)路段，大部分需要

16、加站解決，專項整治計劃進度和質(zhì)量不在項目把控范圍。而目前芯片在測量GSM鄰區(qū)的時延較長，存在LTE弱信號拖死掉話的較大概率。2 案例分析2.1 典型案例案例1：LTE弱覆蓋，eSRVCC切換不及時掉話10:57:29.710基站下發(fā)異頻異系統(tǒng)測量報告，包含2G頻點及B2門限（LTE:-110，GERAN:-95）10:57:38.479，主叫達到B2門限10:57:42.109，主叫RSRP已惡化至-117dBm，SINR至-3，但終端仍沒有上報B2事件10:58:05.587，RTP包不能正常收發(fā)，10s后RTP inactivity定時器觸發(fā)，會話中斷，出現(xiàn)掉話：解決建議：規(guī)范LTE頻點配

17、置，清理多余異頻頻點，縮短終端測量周期；終端芯片提高測量能力，盡快實現(xiàn)CDRX休眠期測量功能。案例2：VoLTE單通現(xiàn)象VoLTE單通現(xiàn)象分為兩類：一是VoLTE打VoLTE單通，二是VoLTE撥打GSM單通。經(jīng)分析，第一類主要是終端問題，第二類主要是網(wǎng)絡(luò)問題。注：紅圈為RTP包抓包位置案例3：eNodeB參數(shù)配置不合理，導(dǎo)致eSRVCC失敗問題現(xiàn)象：終端發(fā)生eSRVCC時，在LTE向GSM切換過程中產(chǎn)生掉話。問題分析：終端可以正常收到測控消息，并上報測量報告，且掉話發(fā)生在向GSM切換過程中，是GSM或者和基站側(cè)參數(shù)設(shè)置問題。問題解決：基站BsCAccess-ID項中的管理狀態(tài)為Locked，

18、設(shè)置有誤。將該狀態(tài)修改為Unlock后，對該站點進行重啟后發(fā)現(xiàn)eSRVCC功能正常。2.2 空口信令判斷案例案例1：RRC重建失敗，無線網(wǎng)問題現(xiàn)象：切換失敗導(dǎo)致RRC釋放，重建RRC未成功，重新進行RRC申請，QCI=1的承載未建立成功，導(dǎo)致掉話分析：呼叫重建失敗后，新小區(qū)重新申請RRC，未能建立VOLTE專載，導(dǎo)致掉話。該流程均由ENODEB控制執(zhí)行。而切換失敗的原因往往是無線環(huán)境問題、參數(shù)配置不合理、鄰區(qū)漏配、非競爭隨機接入異常等，均為無線網(wǎng)問題。結(jié)論：切換失敗與RRC重申請流程均與EUTRAN相關(guān)，因此認定為無線網(wǎng)問題。案例2：基站異常導(dǎo)致雙端無下行信令及RTP包斷傳，無線網(wǎng)問題現(xiàn)象：主

19、被叫VOLTE接通后，在同一小區(qū)同時發(fā)生缺失下行信令20秒，此后數(shù)秒發(fā)生終端上發(fā)bye request掛斷。分析：丟信令之前，主被叫雙端處于同一小區(qū)，且RTP包雙向傳輸正常。丟信令期間，終端測量信息完整，但在2秒后發(fā)生RTP包只有終端向網(wǎng)絡(luò)單向傳輸，未再有任何網(wǎng)絡(luò)下發(fā)的RTP包，高度懷疑基站臨時故障導(dǎo)致。結(jié)論：軟件顯示丟信令，但通過進一步分析確認應(yīng)為基站故障導(dǎo)致。無線網(wǎng)問題。案例3： VOLTE接通下發(fā)生IMS注冊掉話，IMS網(wǎng)絡(luò)問題現(xiàn)象： VOLTE接通后，被叫發(fā)生IMS注冊且成功，此時主叫收到網(wǎng)絡(luò)下發(fā)的bye request內(nèi)含注冊超時字樣分析：按照3GPP協(xié)議，終端應(yīng)在3000秒上發(fā)注冊

20、，本次華為SBC于3600秒才收到注冊請求，此時IMS認為注冊超時，對主叫下發(fā)了sip bye消息釋放了。但通過進一步確認，終端實際于600秒前已上發(fā)了注冊消息（UDP），但此時恰好在G網(wǎng)下，未收到回復(fù)：注：同樣類型的掉話也有600秒前處于LTE網(wǎng)（TCP），而未收到OK或未鑒權(quán)回復(fù)的情況結(jié)論：前10分鐘的注冊失敗，導(dǎo)致了后續(xù)的IMS通話中釋放，雖然終端前一次的失敗處理機制可能存在問題，但仍然體現(xiàn)出IMS對通話中發(fā)生注冊時直接釋放會話的措施欠妥。2.3 網(wǎng)元流程判斷案例案例1：被叫收到尋呼但未收到INVITE請求，核心網(wǎng)問題現(xiàn)象：主叫上發(fā)了invite，被叫收到了尋呼且建立RRC成功，此時應(yīng)收

21、到下行的invite，但始終未收到。分析：被叫響應(yīng)尋呼并進行了RRC申請，表明MME已收到由SGW觸發(fā)的數(shù)據(jù)業(yè)務(wù)請求，即sip invite消息應(yīng)由IMS網(wǎng)元的SBC下發(fā)給了PGW、SGW。Sip invite消息由IMS網(wǎng)元SBC下發(fā)到被叫核心網(wǎng)網(wǎng)元PGWPGW轉(zhuǎn)發(fā)給SGW，SGW通過S11觸發(fā)MME進行尋呼被叫被叫被尋呼到，并完成RRC連接與建立默認承載所需RAB，接收數(shù)據(jù)結(jié)論：收到尋呼消息表示sip invite數(shù)據(jù)包已經(jīng)到達了LTE核心網(wǎng)，未能繼續(xù)下發(fā)當前懷疑是sip數(shù)據(jù)在S/PGW異常丟失。案例2：重配置消息釋放DRB承載，無線網(wǎng)與核心網(wǎng)配合問題現(xiàn)象：被叫上發(fā)sip183后，在激活E

22、PS承載之前，終端上報了1條A3測報，激活EPS后，發(fā)生切換重配置消息中釋放了QCI=1的DRB。分析：起呼時MME進行激活EPS承載流程過程中，恰好發(fā)生S1切換時，由于EPS承載建立未完成，MME在切換準備階段，對下發(fā)到目標小區(qū)的切換準備的請求消息中不攜帶QCI=1的VOLTE專載，導(dǎo)致VOLTE專載源小區(qū)完成的情況下，在目標小區(qū)被釋放，切換完成后呼叫中斷切換準備時，MME向目標小區(qū)發(fā)切換請求，RAB建立請求表只有2條，無QCI=1的專載目標小區(qū)收到MME的切換請求后，回復(fù)的切換確認消息里僅有2條RAB建立MME向源小區(qū)下發(fā)的切換命令消息中，只建立2條承載，導(dǎo)致ENODEB釋放了QCI=1的

23、VOLTE專載。結(jié)論：切換與EPS激活流程碰撞，無線網(wǎng)與核心網(wǎng)配合問題。在進行激活EPS專載過程中，發(fā)生切換時，均會造成上述問題，目前還無較好的解決辦法。2.4 網(wǎng)絡(luò)設(shè)備問題案例總結(jié)案例1：中興ENODEB異頻重定向掉話，無線網(wǎng)問題現(xiàn)象：主被叫VOLTE接通后，服務(wù)小區(qū)信號較差，但未配置異頻鄰區(qū)；通過重定向消息RRC connection release攜帶頻點，由D頻段重定向到F頻段，但VOLTE呼叫不支持重定向方式的RTP包接續(xù)，導(dǎo)致掉話。設(shè)備：中興ENODEB分析：中興設(shè)備為了防止鄰區(qū)漏配情況下，影響用戶在LTE數(shù)據(jù)業(yè)務(wù)下的感知質(zhì)量，默認具備異頻重定向功能，但未曾考慮對VOLTE呼叫的接

24、續(xù)保持。結(jié)論：完善鄰區(qū)配置，在VOLTE呼叫區(qū)域考慮關(guān)閉中興設(shè)備的異頻重定向功能。案例2：華為基站到卡特切換導(dǎo)致的RTP包傳輸中斷問題，無線網(wǎng)問題現(xiàn)象：主被叫接通狀態(tài)下，在發(fā)生一次由華為設(shè)備到卡特設(shè)備的切換后，20秒后主被叫終端同時上發(fā)了bye request消息，網(wǎng)絡(luò)側(cè)回復(fù)bye(487 Request Terminated)，后網(wǎng)絡(luò)去激活了EPS承載，掉話。設(shè)備：華為ENODEB與卡特ENODEB分析：PDCP SN SIZE長度有12bit和7bit，目前華為基站配置為12bit,貝爾配置為7bit，兩個廠家配置數(shù)據(jù)不統(tǒng)一。華為enodeb設(shè)備具有自適應(yīng)功能。在華為小區(qū)起呼時，切換到卡特

25、小區(qū)時，卡特?zé)o自適應(yīng)功能，PDCP SN不一致導(dǎo)致組包混亂。當在貝爾小區(qū)起呼時，切換到華為小區(qū)時，華為PDCP SN自適應(yīng)為7bit，通話正常。結(jié)論：臨時解決方案：華為PDCP SN Size修改為7bit，進行拉網(wǎng)測試主叫呼叫56次，未出現(xiàn)終端主動上發(fā)bye的掉話。異常掉話及切換后單通問題基本解決案例3：愛立信IMS網(wǎng)元CS域呼叫處理能力不足問題，IMS網(wǎng)絡(luò)問題現(xiàn)象：在做互通測試過程中，主叫VOLTE起呼后，被叫始終在TD下未收到尋呼消息，主叫收到網(wǎng)絡(luò)側(cè)下發(fā)trying后，立即收到網(wǎng)絡(luò)下發(fā)的invtie 604（Does Not Exist Anywhere），呼叫失敗。設(shè)備：愛立信IMS分

26、析：空口信令僅能確認，被叫端處于TD網(wǎng)，發(fā)INVITE到MGCF，MGCF回復(fù)604 Does Not Exist Anywhere。該問題為愛立信IMS網(wǎng)元MGCF默認配置僅能同時容納32個CS域呼叫，導(dǎo)致互通測試過程中，由于容量不足，造成大量連續(xù)未接通。結(jié)論：愛立信IMS網(wǎng)元MGCF默認配置容量偏小，發(fā)生以上問題后，經(jīng)過擴容已達可處理2、3G呼叫320個。案例4：華為EPC修改EPS與切換碰撞，拒絕承載修改。核心網(wǎng)問題現(xiàn)象：主叫VOLTE起呼后，收到網(wǎng)絡(luò)回復(fù)trying，激活了EPS承載后，又進行了1次EPS承載的修改，此時主叫側(cè)在發(fā)生了1次LTE的切換后，收到IMS網(wǎng)絡(luò)下發(fā)的sip503消息，服務(wù)不可得。設(shè)備：華為EPC分析：某地在激活EPS完成后，仍需要進行2次EPS承載的修改，本次呼叫時第2次EPS的修改（空口信令不可見）恰好與切換同時發(fā)生，當IMS要求核心網(wǎng)PCRF需要對EPS承載進行修改時，由于切換具有更高的優(yōu)先級，華為EPC拒絕了承載更新，而只執(zhí)行切換，導(dǎo)致IMS下發(fā)sip 503消息中斷呼叫該市合適的CQI=1的EPS承載建立需要3個步驟：CQI=1的初始EPS承載建立，GBR=40kbps但TFT無IPV6地址修改GBR49kbps支持高清語音并對TFT內(nèi)的增加IPV6地址以及 UDP端口進行修改在現(xiàn)有TFT中再新建兩個ptf。結(jié)論：冗余的EP