VoLTE交付關(guān)鍵技術(shù)及優(yōu)化交流_第1頁
VoLTE交付關(guān)鍵技術(shù)及優(yōu)化交流_第2頁
VoLTE交付關(guān)鍵技術(shù)及優(yōu)化交流_第3頁
VoLTE交付關(guān)鍵技術(shù)及優(yōu)化交流_第4頁
VoLTE交付關(guān)鍵技術(shù)及優(yōu)化交流_第5頁
已閱讀5頁,還剩22頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、HUAWEI TECHNOLOGIES CO., LTD.VoLTE交付關(guān)鍵技術(shù)及優(yōu)化交流HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 2內(nèi)容VoLTE E2E架構(gòu)和基本概念1VoLTE優(yōu)化的方法和思路2VoLTE優(yōu)化案例介紹3HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 3VoLTE的網(wǎng)絡(luò)架構(gòu)l關(guān)鍵新部署網(wǎng)元:pSCC AS:支持語音連續(xù)性pATCF/AG

2、CW(集成在SBC):信令與業(yè)務(wù)的本地錨定l關(guān)鍵網(wǎng)元改造:pMSC: 改造支持eSRVCC功能pIMS Core:移動(dòng)終端呼叫控制、路由pSDM:HLR、SAE-HSS、IMS-HSS融合pPCRF:支持VoLTE的QoS控制pEPC:支持IMS APN接入、QoS保證、eSRVCC切換等HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 4VoLTE 呼叫基本流程HLR/HSS1.VoLTE終端開機(jī),自動(dòng)進(jìn)行LTE附著2.觸發(fā)IMS PDN連接的建立,獲得IMS IP地址并建立信

3、令缺省承載3.通過IMS信令承載注冊(cè)到IMS網(wǎng)絡(luò)4.VoLTE終端發(fā)起向另一VoLTE終端的高清語音或視頻呼叫.同時(shí)由P-CSCF通過Rx口發(fā)起語音專有承載建立。5.IMS網(wǎng)絡(luò)對(duì)被叫進(jìn)行尋址呼叫,同步發(fā)起被叫的語音承載建立,被叫振鈴6.被叫摘機(jī),呼叫成功,雙方進(jìn)行通話基本流程EPCMMESAE-PGWASIMSCSCFLTELTESAE-PGWHUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 5主叫: LTE被叫: LTE主叫: UMTS被叫: GSML-L: 優(yōu)選WB-AMR

4、of 23.85 kbpsL-U: WB-AMR of 12.65 kbps is preferredL-G: 使用NB-AMR編碼不同無線制式間編碼及方案建議UMG主/被叫: LTE主/被叫: LTE主/被叫: GSML-L: 優(yōu)選WB-AMR of 23.85 kbps L-G: 使用NB-AMR編碼June, 2013 LTE-LTE下的呼叫,編碼協(xié)商在SBC(會(huì)話邊界控制器)進(jìn)行,基于主、被叫支持的編碼方式。 LTE-CS下的呼叫,編碼協(xié)商在UMG(通用媒體網(wǎng)關(guān))進(jìn)行,基于主、被叫支持的編碼方式。SBC初期建議采用23.85kbps的語音編碼,構(gòu)建VoLTE語音跨代提升的品牌; 容量過

5、載場(chǎng)景采用寬帶23.85kbps和12.65kbps自適應(yīng)網(wǎng)內(nèi)不同無線制式間編碼建議網(wǎng)間不同無線制式間編碼建議HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 6VoLTE無線相關(guān)特性級(jí)策略部署特性功能特性功能 功能簡(jiǎn)介功能簡(jiǎn)介 華為華為建建議議說說明明VOIP LTE網(wǎng)絡(luò)進(jìn)行語音業(yè)務(wù) 開啟 VoLTE語音基本功能,必須開啟eSRVCC 語音業(yè)務(wù)切換到GSM網(wǎng)絡(luò),保證語音業(yè)務(wù)的連續(xù)性保證語音業(yè)務(wù)的連續(xù)性 開啟VoLTE語音連續(xù)性覆蓋保障基本功能,必須開啟RoHC 空口壓縮語音包I

6、P包頭,減小語音包大小,提升系統(tǒng)提升系統(tǒng)容量和覆容量和覆蓋蓋開啟 外場(chǎng)測(cè)試終端支持ROHC, 后續(xù)商用終端需要兼容性測(cè)試TTI bundling上行數(shù)據(jù)包在4個(gè)子幀重復(fù)發(fā)送,增強(qiáng)增強(qiáng)3dB3dB上行覆蓋上行覆蓋 不開啟 當(dāng)前子幀配比DL:UL為3:1,不支持TTL bundling特性(該特性要求上行子幀數(shù)大于或等于下行子幀) 半靜態(tài)調(diào)度 通話期間使用固定的調(diào)度信息,節(jié)省PDCCH資源,提升系統(tǒng)容量提升系統(tǒng)容量 。在高鐵、頻譜1.4M系統(tǒng)帶寬、混合業(yè)務(wù)(語音數(shù)據(jù)并發(fā))及緊急呼叫場(chǎng)景不生效.待終端驗(yàn)證后開啟該特性對(duì)終端和設(shè)備配合要求高,需要完成網(wǎng)絡(luò)和設(shè)備的兼容性測(cè)試,待驗(yàn)證通過后全網(wǎng)開啟DRX

7、不影響語音質(zhì)量的情況下,最大程度保證最大程度保證UEUE的省電能的省電能力力 ?;赒CI進(jìn)行配置開啟 HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 7LTE VoIP 特性介紹 無線為無線為VoLTEVoLTE業(yè)務(wù)建立業(yè)務(wù)建立QCI1QCI1和和QCI5QCI5承載承載(QCI1(QCI1和和QCI5QCI5具有高優(yōu)先級(jí)具有高優(yōu)先級(jí)) ),eNodeBeNodeB優(yōu)先進(jìn)行調(diào)度,保障其帶寬、時(shí)延等,從而優(yōu)先進(jìn)行調(diào)度,保障其帶寬、時(shí)延等,從而為高質(zhì)量的語音通話提供保證為高質(zhì)量的

8、語音通話提供保證 語音編碼由核心網(wǎng)和終端協(xié)商確定語音編碼由核心網(wǎng)和終端協(xié)商確定UE 在Attach時(shí)與Default APN建立數(shù)據(jù)默認(rèn)承載QCI9Attach完成后,UE與IMS APN建立QCI5的默認(rèn)承載,用于傳輸SIP信令VoLTE語音建立QCI1的專用承載,用于傳輸語音;可視電話(視頻)建立QCI1和QCI2的專用承載,分別傳輸語音和視頻VoLTE語音編碼包括AMR-WB和AMR-NB兩種語音編碼方式,語音編碼速率分別有:AMR-NB有8種:12.2K、10.2K、7.95K、7.4K、6.7K、5.9K、5.15K、4.75KAMR-WB有9種: 23.85K、23.05K、19.

9、85K、18.25K、15.85K、14.25K、12.65K、8.85K、6.6K靜默期每160ms發(fā)送一次SID(靜默幀)數(shù)據(jù)業(yè)務(wù)語音業(yè)務(wù)(QCI1&5)Dedicated Bearer(GBR)QCI=2可視電話(QCI1&2&5)HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 8內(nèi)容VoLTE E2E架構(gòu)和基本概念1VoLTE優(yōu)化的方法和思路2VoLTE優(yōu)化案例介紹3HUAWEI TECHNOLOGIES CO., LTD.Huawei prop

10、rietary. No spread without permission.Page 9VoLTE優(yōu)化面臨的困難 眾多因素疊加,導(dǎo)致VoLTE業(yè)務(wù)質(zhì)量提升更加困難 VoLTE業(yè)務(wù)對(duì)弱覆蓋更加敏感VoLTE業(yè)務(wù)對(duì)鄰區(qū)要求更高 上行干擾對(duì)語音質(zhì)量影響大 DHD JGDJ D J DHD JGDJ D J系統(tǒng)復(fù)雜網(wǎng)元眾多定位困難VoLTE業(yè)務(wù)優(yōu)化面臨嚴(yán)峻的挑戰(zhàn)HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 10VoLTE總體優(yōu)化思路VoLTE語音相對(duì)數(shù)據(jù)業(yè)務(wù),對(duì)網(wǎng)絡(luò)覆蓋、鄰區(qū)規(guī)劃、系

11、統(tǒng)干擾、傳輸質(zhì)量等的影響會(huì)更加敏感,對(duì)網(wǎng)絡(luò)優(yōu)化的要求會(huì)更高RF性能是”基礎(chǔ)”、 VoLTE語音質(zhì)量是“重點(diǎn)”、端到端定位是”難點(diǎn)”HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 11接通率優(yōu)化VOLTE呼叫失敗呼叫失敗RRC建立失敗建立失敗QCI1建立失敗建立失敗QCI1沒有建立沒有建立QCI5建立失敗建立失敗QCI1建立后被釋放建立后被釋放空口空口干擾干擾接入接入規(guī)格規(guī)格限制限制SIP注冊(cè)注冊(cè)失敗失敗EPC承載承載刪除刪除SIP流程流程異常異常SIP空口空口超時(shí)超時(shí)EPCQC

12、I1建立異建立異常常PCRF協(xié)協(xié)調(diào)異調(diào)異常常SIP流程流程異常異常SIP空口空口超時(shí)超時(shí)EPC/傳輸傳輸丟包丟包RF,參數(shù)優(yōu)化,參數(shù)優(yōu)化定界解決問題定界解決問題思路:RF原因?qū)е碌腟IP包收發(fā)超時(shí)或丟包問題,與端到端流程異常拉通處理,進(jìn)行分類以展開RF優(yōu)化,或定界到問題產(chǎn)生網(wǎng)元解決相關(guān)問題。手段:通過測(cè)試軟件記錄LOG,同時(shí)進(jìn)行ENODEB、MME、P/SGW、PCRF、IMS多點(diǎn)單用戶信令跟蹤或使用信令平臺(tái),端到端進(jìn)行問題分析。分析思路HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.P

13、age 12掉話率優(yōu)化思路對(duì)于VOLTE通話過程中RRC Release或者SIP信令異常,一般主要是切換失敗、弱覆蓋等空口問題,但也可能是UGW或者IMS等上層問題,因此建議進(jìn)行端到端信令跟蹤,方便問題定位。分分析析思思路路HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 13時(shí)延優(yōu)化思路思路:VOLTE呼叫時(shí)延優(yōu)化的核心方法是還原SIP呼叫流程,逐段評(píng)估,分段優(yōu)化。問題定位方法利用對(duì)比方法,使用實(shí)際測(cè)試值與分段基線數(shù)據(jù)進(jìn)行對(duì)比,找到時(shí)延差異。對(duì)差異部分進(jìn)行分析,給出異常點(diǎn)的優(yōu)

14、化方法。分析思路HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 14某局點(diǎn)MOS分低問題分析幫助評(píng)估設(shè)備新特性的引入MOS優(yōu)化思路排除評(píng)分標(biāo)準(zhǔn),語音編碼方式,測(cè)試設(shè)備,語料差異外,丟包,時(shí)延和抖動(dòng)是影響語音質(zhì)量的關(guān)鍵指標(biāo),也是無線側(cè)優(yōu)化重點(diǎn)需要關(guān)注。42%的低分由鄰區(qū)問題導(dǎo)致32%的低分由PCI干擾導(dǎo)致uMOS低分:主要受RF優(yōu)化效果影響,最為突出有鄰區(qū)漏配、模3干擾、頻繁切換等問題造成HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietar

15、y. No spread without permission.Page 15eSRVCCeSRVCC切換優(yōu)化切換優(yōu)化開通基于覆蓋的eSRVCC需要對(duì)現(xiàn)網(wǎng)參數(shù)做相關(guān)的調(diào)整。以下是對(duì)A2參數(shù)的分析:高高高高低低低低時(shí)間點(diǎn)時(shí)間點(diǎn)LTE RSRPLTE RSRP低于低于A2A2,UEUE上報(bào)上報(bào)A2A2事件事件- -eNodeBeNodeB下發(fā)下發(fā)B1B1測(cè)量指示測(cè)量指示-UEUE開始測(cè)量開始測(cè)量GSMGSM信號(hào)信號(hào)時(shí)間點(diǎn)時(shí)間點(diǎn)UEUE測(cè)量發(fā)現(xiàn)測(cè)量發(fā)現(xiàn)GSMGSM電平高電平高于高于于高于B1_GSMB1_GSM,上報(bào)上報(bào)B1B1事件事件-eNodeBeNodeB發(fā)起到發(fā)起到GSMGSM的的eSRVC

16、CeSRVCC時(shí)間點(diǎn)時(shí)間點(diǎn)UE未測(cè)量到滿足B1條件的GSM信號(hào),當(dāng)當(dāng)LTE RSRPLTE RSRP低于低于A2_A2_盲盲,UEUE上上報(bào)報(bào)A2A2盲事盲事件-eNodeBeNodeB發(fā)起到發(fā)起到TDSTDS的盲重定向,的盲重定向, 語音業(yè)務(wù)中斷語音業(yè)務(wù)中斷 eSRVCC需要啟動(dòng)對(duì)GSM鄰區(qū)進(jìn)行測(cè)量,切換到GSM 在eSRVCC過程中,如果UE不支持異系統(tǒng)測(cè)量,網(wǎng)絡(luò)不會(huì)下發(fā)異系統(tǒng)測(cè)量控制,會(huì)等到時(shí)間點(diǎn)時(shí)直接發(fā)起到TDS的盲重定向 針對(duì)并發(fā)業(yè)務(wù),如果GSM不支持DTM,則用戶的PS數(shù)據(jù)業(yè)務(wù)被掛起LTE RSRPLTE RSRPGSMGSMA2A2_盲B1_GSM用戶逐步移動(dòng)到用戶逐步移動(dòng)到LT

17、ELTE覆蓋邊緣覆蓋邊緣TimeTime需要調(diào)整現(xiàn)網(wǎng)參數(shù),激活2G 測(cè)量切換準(zhǔn)備切換測(cè)量切換執(zhí)行:用戶面中斷語音結(jié)束:返回LTE小區(qū)重選/終端自主FRHUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 16內(nèi)容內(nèi)容VoLTE E2E架構(gòu)和基本概念1VoLTE優(yōu)化的方法和思路2VoLTE優(yōu)化案例介紹3HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 17Tcall定時(shí)器

18、超時(shí)導(dǎo)致未接通主叫終端發(fā)起呼叫嘗試,10s后觸發(fā)CSFB流程,最終出現(xiàn)未接通事件。 問題現(xiàn)象 問題結(jié)論 問題分析 優(yōu)化建議聯(lián)合IMS側(cè)確認(rèn)IMS側(cè)是否收到INVITE消息,如果收到需要確認(rèn)主叫終端為什么沒有收到100 trying消息。從sip消息上看,主叫終端發(fā)送INVITE消息后,10s后向網(wǎng)絡(luò)側(cè)發(fā)送cancel消息,在此過程中未收到網(wǎng)絡(luò)側(cè)的100 TRYING消息,主叫終觸發(fā)轉(zhuǎn)CSFB流程。主叫終端發(fā)送INVITE消息后,10s后未收到網(wǎng)絡(luò)側(cè)的100 TRYING消息,導(dǎo)致TCALL定時(shí)器超時(shí),終端會(huì)向IMS發(fā)送cancel,出現(xiàn)未接通事件。HUAWEI TECHNOLOGIES CO.

19、, LTD.Huawei proprietary. No spread without permission.Page 18MME切換和QCI=1承載建立沖突導(dǎo)致未接通被叫終端QCI1承載建立不成功,TQOS定時(shí)器超時(shí)后,發(fā)580錯(cuò)誤碼,呼叫建立失敗。 問題現(xiàn)象 問題結(jié)論 問題分析 優(yōu)化建議協(xié)議23401明確規(guī)定若切換流程和E-RAB建立沖突時(shí),有以下規(guī)定:切換和E-RAB建立流程發(fā)生沖突,eNodeB優(yōu)先處理切換,在切換完成后,核心網(wǎng)會(huì)重新嘗試建立dedicated EPS bearer。推動(dòng)MME進(jìn)行升級(jí)解決。uEPC下切換、TAU等和QCI=1承載建立沖突,導(dǎo)致切換完成后未能正常建立QC

20、I=1承載。QCI1承載建立流程和切換流程同時(shí)發(fā)生,MME未收到終端發(fā)送的QCI1承載激活確認(rèn)的NAS消息,就發(fā)生切換,在向新ENOIDEB發(fā)送的HANDOVER REQUEST消息中,未帶QCI1的承載信息,導(dǎo)致切換到新小區(qū)后,QCI1承載未能正常建立,在EPC側(cè)引入沖突解決機(jī)制來規(guī)避被叫終端QCI1承載建立不成功,TQOS定時(shí)器超時(shí)后,發(fā)580錯(cuò)誤碼,呼叫建立失敗。HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 19MME下發(fā)釋放上下文命令導(dǎo)致掉話主叫終端從sip信令流程上

21、看,信令完整,不存在掉話,在L3信令看到,終端收到了網(wǎng)絡(luò)下發(fā)的rrc connect rel消息,導(dǎo)致掉話。 問題現(xiàn)象 問題結(jié)論 問題分析 優(yōu)化建議uMME給eNodeB下發(fā)釋放上下文命令導(dǎo)致基站給UE下發(fā)了RRC Release消息。MME釋放上下文的原因值為release due to eutran generated reason ,一般和空口問題較大,優(yōu)先對(duì)掉話路段進(jìn)行RF優(yōu)化,后續(xù)需要對(duì)原因進(jìn)行研究和細(xì)分。主叫終端建從sip信令流程上看,信令完整,不存在掉話,查看終端的L3消息,終端處于弱覆蓋場(chǎng)景,最后收到了網(wǎng)絡(luò)下發(fā)的rrc connection rel消息,原因致為other。從虛

22、用戶跟蹤來看是MME下發(fā)的釋放上下文命令,原因?yàn)閞elease due to eutran generated reason。HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 20RRC重建失敗TAU后承載被MME釋放導(dǎo)致掉話(1)終端發(fā)起rrc重建,重建被拒絕后,終端發(fā)起TAU更新,TAU更新完成后,收到網(wǎng)絡(luò)下發(fā)的rrc rel消息。 問題現(xiàn)象 問題分析從L3信令來看,終端發(fā)起rrc重建,重建被拒絕后,終端發(fā)起TAU更新,TAU更新完成后,收到網(wǎng)絡(luò)下發(fā)的rrc rel消息。從S

23、IP信令來看終端正常完成了本次通話, 09:35:56到09:42:00 。從EPC來看,EPC收到的是初始的TAU更新,并且不需要建立承載,所有TAU完成后,會(huì)釋放本次業(yè)務(wù)。這次TAU是initial TAU,USN判斷為空閑態(tài)TAU,(連接態(tài)TAU應(yīng)該走NAS UPLINK消息),同時(shí)TAU request的的active flag攜帶的是0。TAU完成后釋MME下發(fā)了釋放終端上下文的命令。HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 21RRC重建失敗發(fā)起TAU后承載被

24、MME釋放導(dǎo)致掉話(2) 根據(jù)23401協(xié)議: MME目前的實(shí)現(xiàn)是符合協(xié)議規(guī)范的,空閑態(tài)的tau,active-flag=0時(shí),tau完成后需要釋放連接。 問題結(jié)論 優(yōu)化建議u終端在RRC重建失敗后,發(fā)起TAU更新,由于此時(shí)20ms一次的上行用戶面數(shù)據(jù)(RTP語音包)還沒到,終端認(rèn)為此時(shí)入網(wǎng)初始TAU消息,將active-flag置為0,從而MME在完成TAU后下發(fā)了釋放上下文消息,從而導(dǎo)致VOLTE掉話。u終端新版本改進(jìn),只要沒有正常收到或者發(fā)送cancel或bye消息,都算作業(yè)務(wù)態(tài),業(yè)務(wù)態(tài)的tau都會(huì)將activeflag設(shè)置為1,規(guī)避了此種場(chǎng)景下的掉話 。 根據(jù)協(xié)議TS24.301 5.

25、5.3.2.2章節(jié)的規(guī)定,終端在RRC重建失敗的情況下發(fā)送TAU是符合預(yù)期的。i) when the UE receives an indication of RRC Connection failure from the lower layers and has no signalling or user uplink data pending (i.e when the lower layer requests NAS signalling connection recovery); 在準(zhǔn)備發(fā)送TAU時(shí),若20ms一次的上行用戶面數(shù)據(jù)(RTP語音包)還沒有,則不會(huì)置active標(biāo)示。若此時(shí)

26、有上行用戶面數(shù)據(jù),則會(huì)置active標(biāo)示。從L3信令來看,終端發(fā)送Service Request是20ms一次的上行RTP包觸發(fā)的。HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 22接入時(shí)延長(zhǎng)類典型問題:DRA信令傳輸方式導(dǎo)致系統(tǒng)性解決建議:無線網(wǎng)絡(luò)對(duì)接入時(shí)延影響較小,主要決定上層網(wǎng)元的處理方式,建議統(tǒng)一配置規(guī)范DRA優(yōu)化前優(yōu)化前DRA優(yōu)化后優(yōu)化后u接入時(shí)延主要由上層網(wǎng)元決定,無線側(cè)的時(shí)延占比很少,且無法進(jìn)一步優(yōu)化HUAWEI TECHNOLOGIES CO., LTD.Hu

27、awei proprietary. No spread without permission.Page 23乒乓切換對(duì)MOS影響切換前后MOS值分析,切換前MOS值3.33,終端在53、473小區(qū)乒乓切換,導(dǎo)致MOS值降到2.12.而在RSRP較好切換一次場(chǎng)景,MOS值下降并不明顯.切換對(duì)MOS值并不一定影響非常大,RSRP較好地方切換MOS值下降0.10.5,而乒乓切換MOS值下降0.51.5分。乒乓切換,MOS值下降明顯正常RSRP較好點(diǎn)切換,MOS下降不明顯HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without

28、 permission.Page 24跨廠家參數(shù)配置規(guī)范問題,造成切換后單通系統(tǒng)性解決建議:異廠家交界區(qū)域,建議統(tǒng)一參數(shù)配置規(guī)范異廠家基站配置不同PDCP SN bit長(zhǎng)度,語音用戶在切換后,由于KT基站帶給HW切換請(qǐng)求的PDCP SN bit長(zhǎng)度和實(shí)際從KT切換到HW的UE使用的PDCP SN bit長(zhǎng)度不一致,導(dǎo)致基站和UE的配置不同,進(jìn)而導(dǎo)致數(shù)據(jù)包由于封裝和解封不一致而丟棄,出現(xiàn)單通或者雙不通的現(xiàn)象。HUAWEI TECHNOLOGIES CO., LTD.Huawei proprietary. No spread without permission.Page 25系統(tǒng)性解決建議:典型場(chǎng)景需要終端和網(wǎng)絡(luò)側(cè)共同改進(jìn),以改善互操作成功率,確保用戶感知互操作成功率低典型問題:eSRVCC測(cè)量時(shí)間長(zhǎng)導(dǎo)致互操作失敗4G信號(hào)2G信號(hào)場(chǎng)景描述測(cè)試結(jié)果漸弱好電梯、車庫(kù) 觸發(fā)22

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論