移動路測-鼎利-黃文學(xué)volte培訓(xùn)與交流

VoLTE培訓(xùn)與交流珠海世紀鼎利通信科技股份有限公司第一章第三章第四章VoLTE如何學(xué)習(xí)VoLTE主要流程VoLTE技術(shù)要點第五章VoLTE幾個案例第二章VoLTE新業(yè)務(wù)什么是VoLTE?2G/TDIMS網(wǎng)絡(luò)LTELTE多模終端InternetCS網(wǎng)絡(luò)EPC網(wǎng)絡(luò)LTE多模終端語音及多媒體業(yè)務(wù)數(shù)據(jù)業(yè)務(wù)EPC實現(xiàn)移動性管理和接入鑒權(quán)為通信和數(shù)據(jù)業(yè)務(wù)建立承載通道IMS提供通信業(yè)務(wù)控制能力LTE無CS域，語音和數(shù)據(jù)均走PS域VoLTE是通過LTE網(wǎng)絡(luò)作為業(yè)務(wù)接入、IMS網(wǎng)絡(luò)實現(xiàn)業(yè)務(wù)控制的語音解決方案業(yè)務(wù)接入：LTE網(wǎng)絡(luò)是全IP網(wǎng)絡(luò)，沒有CS域，數(shù)據(jù)業(yè)務(wù)和語音多媒體業(yè)務(wù)都承載在LTE上業(yè)務(wù)控制：EPC網(wǎng)絡(luò)不具備語音和多媒體業(yè)務(wù)的呼叫控制功能，需要通過IMS網(wǎng)絡(luò)提供業(yè)務(wù)控制功能業(yè)務(wù)切換：在LTE全覆蓋之前，需要通過eSRVCC技術(shù)實現(xiàn)LTE與CS之間的語音業(yè)務(wù)連續(xù)性VoLTE（VoiceoverLongTermEvolution，長期演進上的語音）3GPP標準定義的：基于IMS網(wǎng)絡(luò)的LTE語音解決方案。通過IMS網(wǎng)絡(luò)，移動運營商不僅可以無縫的繼承傳統(tǒng)的語音、短消息業(yè)務(wù)，還可以將語音通話與豐富的增強功能相整合，提供多樣化的服務(wù)。為什么是IMS？VOLTE是什么？最直接簡單的理解就是VOIP，與普通VOIP相比，網(wǎng)絡(luò)的承載體由互聯(lián)網(wǎng)變成了LTE，同時對VoLTE使用的DRB承載定義高優(yōu)先級及速率保障等，保證業(yè)務(wù)QOS。IMS發(fā)展史IMS定義最早出現(xiàn)在3GPPR5階段,作為PS域的一個子系統(tǒng)出現(xiàn)2001/032002/032005/122006/X3GPPR4CN:MSC服務(wù)器和MGW3GPPR6IMSQoS,Billing,FMC,等3GPPR7IMS增強3GPPR5CN:IMS子系統(tǒng)和大量相關(guān)新網(wǎng)元TISPANR1--NGN/FMC等TISPANR2--NASS/RACS,等為保證標準的一致性，經(jīng)過各標準化組織之間的協(xié)調(diào)，在3GPP中統(tǒng)一開展CommonIMS相關(guān)的標準化工作3GPPR8

引入LTE，基于LTE提供VoLTE3GPPR9

SRVCC支持緊急呼叫3GPPR10

eSRVCC漫游方案3GPPR11

rSRVCCvSRVCC2008/122009/122011/32012/9IMS的驅(qū)動力IP多媒體FMCWebIP是通過電信與互聯(lián)網(wǎng)同步實現(xiàn)全業(yè)務(wù)的基礎(chǔ)TDMIP挖掘網(wǎng)絡(luò)潛力，實現(xiàn)純語音業(yè)務(wù)向多媒體能力的轉(zhuǎn)變語音多媒體用戶需求推動固網(wǎng)移動的融合固網(wǎng)和移動網(wǎng)

FMC固網(wǎng)移動融合通過Web實現(xiàn)電信網(wǎng)的運營維護及業(yè)務(wù)操作電信業(yè)務(wù)操作與管理

WebIMS到底是啥？IMS：IPMultimediaSubsystem

IMS是在3GPPR5階段提出的一個新的域，它基于IP承載，疊加在PS（分組域）之上，為用戶提供文本、語音、視頻、圖片等不同的IP多媒體信息.IP=

基于IP的傳輸基于IP的會話控制基于IP的業(yè)務(wù)實現(xiàn)Multimedia=

語音、視頻、圖片、文本等多種媒體的組合在多種接入基礎(chǔ)之上具有不同能力的終端組合Subsystem=

依賴于現(xiàn)有網(wǎng)絡(luò)技術(shù)和網(wǎng)絡(luò)設(shè)備發(fā)展的系統(tǒng)最大程度重用現(xiàn)有網(wǎng)絡(luò)系統(tǒng)無線網(wǎng)絡(luò)把GSM/WCDMA/CDMA/TD-SCDMA/LTE/SAE/WiMax網(wǎng)絡(luò)作為承載網(wǎng)絡(luò)固定網(wǎng)絡(luò)把基于固定接入IP系統(tǒng)(LAN、WLAN、xDSL)作為承載網(wǎng)絡(luò)簡言之：IMS在IP網(wǎng)絡(luò)的基礎(chǔ)上構(gòu)建一個分層、開放、融合的核心網(wǎng)控制架構(gòu)，是一個可運營、可管理、可計費的系統(tǒng)。IMS將是未來固網(wǎng)移動統(tǒng)一的核心網(wǎng)架構(gòu)融合已經(jīng)成為電信業(yè)發(fā)展的主要趨勢。IMS相關(guān)國際標準趨于統(tǒng)一，以commonIMS的推出為代表，IMS的標準化工作發(fā)展到了一個新的階段。以3GPP、TISPAN的合作為主，包括ITU-T、OMA、3GPP2、PARLAY等研究組織。

一個融合了固定接入和移動接入的統(tǒng)一架構(gòu)，能夠提供豐富業(yè)務(wù)的網(wǎng)絡(luò)平臺離我們越來越近了。3GPP是IMS標準的發(fā)起者和主要貢獻者；3GPP與ETSITISPAN合作成立了3GPPOPadhoc小組，基于現(xiàn)有的3GPPIMS標準，制訂全球通用的，可同時用于移動、固網(wǎng)、固網(wǎng)移動融合的IMS標準;3GPP2引用IMS標準并基于CDMA特性制定MMD標準;OMA定義各種IMS業(yè)務(wù)，其標準被3GPP直接引用，作為IMS業(yè)務(wù)層的相關(guān)標準;Parlay組織定義標準的API框架；IETF定義IMS下的SIP、SDP與其他協(xié)議；ITU-T的體系架構(gòu)和基本理念與3GPP基本一致。應(yīng)該說IMS給LTE的業(yè)務(wù)發(fā)揮提供了更多的可能狹義的看VoLTE就是語音業(yè)務(wù)在LTE網(wǎng)絡(luò)上得以實現(xiàn)廣義的講基于LTE承載的IMS的多媒體業(yè)務(wù)都可以稱呼為VoLTE基本通訊類業(yè)務(wù)VoIP視頻通話會議電話電信補充業(yè)務(wù)VPMN業(yè)務(wù)IPCentrex業(yè)務(wù)......增強型通訊業(yè)務(wù)即時消息視頻共享電子白板應(yīng)用共享......提升用戶體驗呈現(xiàn)業(yè)務(wù)群組管理動態(tài)號碼簿一號通業(yè)務(wù)……多媒體業(yè)務(wù)多媒體彩鈴多媒體彩像多媒體會議......其他個性化業(yè)務(wù)統(tǒng)一用戶自服務(wù)

彩鈴、彩像……那么從無線優(yōu)化分析而言，VoLTE該如何學(xué)習(xí)呢？BOSSNMSOMC支撐系統(tǒng)業(yè)務(wù)平臺核心網(wǎng)IMS域分組域PCC2G/3G電路域eNodeBBTS/BSCLTE接入接入網(wǎng)2G接入終端VoLTEUEI/S-CSCF/BGCF信令網(wǎng)用戶數(shù)據(jù)DRAPCRFVoLTESBCMGCFIBCFSAEGW/GGSN/PCEF三合一HSSDNS/ENUM(e)MSCGMSC彩印業(yè)務(wù)平臺彩鈴業(yè)務(wù)平臺VoLTE

AS/IM-SSF智能網(wǎng)SCPMME/SGSNIP短信網(wǎng)關(guān)ShMwSGiRxGxMxSvS11/GnMg/MjNcNcCAPCAPS1-MMES1-UUuMw/I2UmAGbISC承載網(wǎng)定位業(yè)務(wù)平臺CxRx/GxS6a/SLgCx/Sh/Zh/S6a/SLhSLh/SLgSLs承載網(wǎng)JUtGm業(yè)務(wù)配置代理網(wǎng)關(guān)UtZhC/DGr1、VoLTE帶來了哪些新業(yè)務(wù)？2、VoLTE引入了哪些新技術(shù)？3、VoLTE引入的新協(xié)議和業(yè)務(wù)流程？第一章第三章第四章VoLTE如何學(xué)習(xí)VoLTE主要流程VoLTE技術(shù)要點第五章VoLTE幾個案例第二章VoLTE新業(yè)務(wù)“新通話、新消息、新聯(lián)系”，VoLTE是“三新”業(yè)務(wù)的核心新通話:利用VoLTE，實現(xiàn)更高質(zhì)量的用戶體驗終端內(nèi)的本地入口新聯(lián)系:實名社交網(wǎng)絡(luò)、公眾信息和個人服務(wù)的入口新消息:基于RCS，無縫對接各種格式的消息和媒體新通話：支持各種網(wǎng)絡(luò)環(huán)境，新增多方、高清等作為亮點視頻(LTE)音頻（CS/LTE）多方通話以VoLTE為核心能力，提供多種網(wǎng)絡(luò)環(huán)境下的高清音視頻通話和多方通話。并且吸取RCS國際標準定義，提供通話中的切換、消息收發(fā)等新功能。新消息：與OTT體驗看齊群聊群發(fā)點對點消息新消息在提供多種媒體格式消息收發(fā)的基礎(chǔ)上，繼承原有一對一和群發(fā)通信能力，新增基于群組的聊天和公眾賬號交互等社交功能。新聯(lián)系：以真實手機號為前提，構(gòu)建全新的社交、公眾信息服務(wù)入口個性化展示“我”獲取公眾服務(wù)的入口融合通信能力展現(xiàn)實名制群組社交通訊錄社交一對多無縫通信豐富的聯(lián)系人類型個人資料管理入口本人頭像個人詳細信息二維碼名片滿足社交及商務(wù)工作多個場景個性化的增強屏顯業(yè)務(wù)辦理的入口賬單查詢套餐辦理業(yè)務(wù)設(shè)置一卡多號彩鈴、彩印增強的聯(lián)系人功能基于云存儲的聯(lián)系人備份/恢復(fù)黑名單管理，防騷擾表情商店，讓聊天更輕松有趣第一章第三章第四章VoLTE如何學(xué)習(xí)VoLTE主要流程VoLTE技術(shù)要點第五章VoLTE幾個案例第二章VoLTE新業(yè)務(wù)VoLTE關(guān)鍵技術(shù)關(guān)鍵技術(shù)半持續(xù)調(diào)度（SPS）魯棒頭壓縮（ROCH）時隙綁定（TTIBundling）QoS/PCC國際IP轉(zhuǎn)接（IPX）核心特性VoIMS/SIPeSRVCCHD

voice/ARM-WBHDvideo/H.264VoLTE語音暫態(tài)(TransientState)暫態(tài)是指每次業(yè)務(wù)建立初期尚未穩(wěn)定的狀態(tài)，此狀態(tài)下的數(shù)據(jù)包較大。通話期(Talkspurts)通話期是指對應(yīng)用戶正在通話的狀態(tài)，在通話狀態(tài)下，每20ms傳送一次數(shù)據(jù)。通話期的語音包大小取決于當(dāng)前采用的編碼速率。靜默期(SilentPeriod)靜默期是對應(yīng)用戶通話停頓的狀態(tài)，每間隔160ms發(fā)一個很短的SID（SilenceInsertionDescriptor）幀。SID幀是為了提升用戶感受而發(fā)送的噪音幀。

※AdaptiveMulti-Rate(AMR)

VoIP業(yè)務(wù)存在3個狀態(tài)：:

Semi-persistentScheduling（一）※應(yīng)用場景半持續(xù)調(diào)度主要用于周期性小包業(yè)務(wù)，可以減少L1/L2控制信令的開銷，目前調(diào)度器只針對QCI為1的VoLTE語音業(yè)務(wù)進行半持續(xù)調(diào)度（是否對其它QCI類型支持半持續(xù)調(diào)度與廠家相關(guān)）。※目的

半靜態(tài)地為VoLTE用戶分配資源

?！δ躒oLTE業(yè)務(wù)的通話期與靜默期狀態(tài)由PDCP層進行判決，判決為通話期時，激活半持續(xù)調(diào)度；判決為靜默期時，釋放已分配的半靜態(tài)資源；當(dāng)業(yè)務(wù)從靜默期轉(zhuǎn)為通話期時，需要重新激活半持續(xù)調(diào)度。eNodeB激活半持續(xù)調(diào)度時，通過PDCCH指示UE配置的半持續(xù)調(diào)度資源，在周期調(diào)度過程中，無需通過PDCCH指示調(diào)度資源。半持續(xù)調(diào)度的周期為20ms，由eNodeB通過RRC消息傳送給UE。Semi-persistentScheduling（二）對于上行，UE會在指定的半持續(xù)調(diào)度資源上周期發(fā)送數(shù)據(jù)。半持續(xù)調(diào)度激活前，需要對VoLTE數(shù)據(jù)包采用動態(tài)調(diào)度。在半持續(xù)調(diào)度激活后，在以下場景需要采用動態(tài)調(diào)度作為半持續(xù)調(diào)度的補充：靜默期、半持續(xù)調(diào)度期間的大包以及信令、HARQ重傳數(shù)據(jù)判斷VoLTE業(yè)務(wù)為通話期后，嘗試激活半持續(xù)調(diào)度，根據(jù)語音包大小和調(diào)整后的全帶SINR得到半持續(xù)調(diào)度激活時MCS和RB。對于下行，eNodeB周期發(fā)送數(shù)據(jù)，UE在指定的半持續(xù)調(diào)度資源上周期接收數(shù)據(jù)。下行半持續(xù)調(diào)度的優(yōu)先級低于廣播、尋呼等公共控制信息，高于用戶級控制信令和數(shù)據(jù)面的傳輸。半持續(xù)調(diào)度激活時，根據(jù)VoIP數(shù)據(jù)包大小和UE上報的全帶寬CQI，為用戶分配MCS和RB。由于半持續(xù)調(diào)度用戶的MCS在通話期間固定不變，而實際信道環(huán)境是變化的，會造成部分用戶的IBLER（InitialBlockErrorRate）較高，為了保證半持續(xù)調(diào)度用戶IBLER收斂到一定范圍之內(nèi)，會根據(jù)IBLER的收斂狀況決定是否進行半持續(xù)調(diào)度重激活。Semi-persistentScheduling

VSDynamicScheduling※好處

保障VoIP的QoS減少PDCCH消耗，提高VoIP容量※壞處(相對于動態(tài)調(diào)度)

受限于終端能力(是否支持半持續(xù)調(diào)度)

由于兩次半持續(xù)調(diào)度之間的MCS是固定的，鏈路適應(yīng)能力不好※好處更好包裝VoIP業(yè)務(wù)的QoS

對終端能力沒有限制(是否支持半持續(xù)調(diào)度)

對于不同的無線環(huán)境兼容性更好※壞處(相對于半持續(xù)調(diào)度)

消耗大量PDCCH資源，容量低于半持續(xù)調(diào)度。在VoIP用戶較多的場景不建議采用動態(tài)調(diào)度。

ULSemi-persistentSchedulingPowerControl※

功能

包括PUSCH開環(huán)功控和閉環(huán)功控?OpeningLoopPowerControl設(shè)置初速功率為

Po(P0_nominal_pusch

).?ClosedLoopPowerControlIBLER測量值大于IBLERTarget，eNodeB向UE發(fā)送增大發(fā)射功率的TPC命令。IBLER測量值小于IBLERTarget，eNodeB向UE發(fā)送降低發(fā)射功率的TPC命令。eNodeB發(fā)送TPC給終端，終端計算傳輸功率DLSemi-persistentSchedulingPowerControl※目的

保障IBLER收斂于IBLERTarget?！鶓?yīng)用場景

下行覆蓋受限。※功能

當(dāng)子開關(guān)打開時，對于采用QPSK調(diào)制方式的用戶，eNodeB根據(jù)VoIP數(shù)據(jù)包的IBLER（InitialBlockErrorRate）測量值和IBLERTarget間的差異，周期性調(diào)整PDSCH發(fā)射功率，以滿足IBLERTarget要求。如果IBLER測量值小于IBLERTarget，減小發(fā)射功率。如果IBLER測量值大于IBLERTarget，增大發(fā)射功率。

ROCH（一）※目的?減少語音包頭大小，提高邊緣用戶的語音覆蓋。在容量受限時，提升用戶容量?！鶓?yīng)用場景?

業(yè)務(wù)層穩(wěn)定小包場景。

eNBeNB…VoIPUserVoIPUserIPHeader40BytesAMRframe32BytesRoHC1BytesAMRframe32BytesRoHC1BytesAMRframe32BytesIPHeader40BytesAMRframe32BytesIPHeader40BytesAMRframe32BytesULpressionDLpressionDLCompressionULCompressionOriginalpacketCompressedpacketROCH（二）※ROHC增益

下面表格是IPV4場景下，AMR-NB和AMR-WB各種SDU對應(yīng)的壓縮效率。AMR-NBcodec(kbps)SDUbitbandwidth-efficientAMRpayload(octet)VoIPFramewithIPheader(withoutROHC),(octet)VoIPFramewithIPheader(withROHC),(octet)VoIPFrame（withROHC）/VoIPFramewithoutROHC12.224432723548.61%10.220427673044.78%7.9515922622540.32%7.414820602338.33%6.713418582136.21%5.911816561933.93%5.1510315551832.73%4.759514541731.48%SID(1.8)397471021.28%AMR-WB

codec(kbps)SDUbitbandwidth-efficientAMRpayloadVoIPFramewithIPheader(withoutROHC)VoIPFramewithIPheaderr(withROHC),(octet)VoIPFrame（withROHC）/VoIPFramewithoutROHC23.85477611016463.37%23.0546159996262.63%19.8539751915459.34%18.2536547875057.47%15.8531741814454.32%14.2528537774051.95%12.6525333733649.32%8.8517724642742.19%6.613218582136.21%SID(1.75)407471021.28%TTIBundling

※應(yīng)用場景

VoIP用戶上行覆蓋受限時.※目的

增加小區(qū)邊界VoIP用戶的上行覆蓋。

※功能

以下兩個條件必須滿足:

在連續(xù)超過配置值（T_COVERAGE_STAT）的TTI中由于功率受限，分配用戶的RB書小于3RB。終端的平均SINR小于threshold(packetlength).

綁定4個TTI用于一個包的傳輸。終端在4個TTI中提供非自適應(yīng)的重傳。捆綁在一起的4個傳輸采用同一個HARQ進程。TDD系統(tǒng)中，協(xié)議規(guī)定TTIbundling只支持子幀配比0、1、6，且跟半持續(xù)調(diào)度互斥。QoS/PCC（PolicyControlandCharging）S-GWLTEPGWeNodeBInternetIMS/P-CSCFPCRF/SPRGxRx1。根據(jù)業(yè)務(wù)請求申請承載資源媒體信息/資源需求QCI/GBR2。根據(jù)業(yè)務(wù)簽約判斷是否允許申請承載資源QCI/GBRQCI/GBR3。根據(jù)QCI調(diào)度上下行資源4。根據(jù)QCI調(diào)度上下行資源5。根據(jù)QCI調(diào)度上行資源終端LTERAN傳輸網(wǎng)PGW用戶會話缺省承載專有承載普通上網(wǎng)業(yè)務(wù)/QCI=9普通P2P業(yè)務(wù)/QCI=9視頻/QCI=2，由PGW動態(tài)建立PCRF的關(guān)鍵作用：根據(jù)業(yè)務(wù)簽約判斷用戶所使用業(yè)務(wù)的QoS信息，也即默認承載或?qū)Ｓ谐休d打開管道看在傳統(tǒng)CS域，每路話音都是獨占資源，互不影響。體驗是能夠保障的。在數(shù)據(jù)業(yè)務(wù)域，帶寬是共享的，VoLTE流量也是流量的一部分。PCC的專有承載能力，為VoLTE話音提供了專有數(shù)據(jù)通道，能夠保證QoS質(zhì)量。如果沒有PCRF，VoLTE通話質(zhì)量將無法達到傳統(tǒng)CS話音的體驗水平。語音/QCI=1，由PGW動態(tài)建立SIP信令/QCI=5，在Attach時同步建立.DefaultAPNIMSAPNQoS/PCC（PolicyControlandCharging）視頻電話QCI5QCI1QCI2QCI8/9語音電話QCI5QCI1QCI8/9優(yōu)先級24QCI1235134567867899典型業(yè)務(wù)VoIP電話會議,會話視頻(直播流媒體)實時在線游戲,實時工業(yè)監(jiān)控非會話視頻(緩沖流媒體)IMS信令視頻(緩沖流媒體)視頻(直播流媒體),話音業(yè)務(wù)交互式游戲E-Mail,MSN,QQ,WWWP2P文件共享資源類型GBRGBRGBRGBRNon-GBRNon-GBRNon-GBRNon-GBRNon-GBR時延100ms150ms50ms300ms100ms300ms100ms300ms300ms丟包率(-2)10(-3)10(-3)10(-6)10(-6)10(-6)10(-3)10(-6)10(-6)10VoLTE協(xié)議棧半持續(xù)調(diào)度SPSPHY3GPP36.21XTTIBundingMAC3GPP36.321RLC3GPP36.322SN、完保、加密、頭壓縮SN、完保、加密、頭壓縮PDCP3GPP36.323RRC信令RRC3GPP36.331承載NAS3GPP24.301LTE承載LTE控制面LTE用戶面IP包IP加密-ESP報文TCPTLSUDP信令壓縮（可選）SIPRTPRTCP控制信令用戶數(shù)據(jù)語音幀語音包控制信令3GPP23.228IMS3GPP24.22824.229SIP相關(guān)協(xié)議RFC3261：SIP協(xié)議RFC3550：RTPRFC4566：RTCPSDPRFC2617：HTTP協(xié)議RFC768：UDP協(xié)議RFC793：TCP協(xié)議RFC791：IP協(xié)議VoLTE在各網(wǎng)元的配置要求前提：VoLTE用戶已經(jīng)可以在LTE網(wǎng)絡(luò)進行普通數(shù)據(jù)業(yè)務(wù)。1）IMS：需要配置VoLTE用戶賬號并提供到終端的用戶路由。2）PCRF：需要保障與P-CSCF的Rx接口正常并配置Voice承載QCI1策略。3）EPC（UGW）：需要為用戶新增一個APN——IMSAPN數(shù)據(jù)的配置以及與PCRF相關(guān)數(shù)據(jù)。4）eNodeB：需要開啟eNodeB增強調(diào)度算法以及配置SIP承載QCI5的RLC模式為AM和Voice承載QCI1的RLC層模式為UM。5）終端：需要配置IMS信息、VoIP賬號信息以及新增IMSAPN的配置。

語音編碼（一）VoIP常用的語音編/解碼標準包括3GPP采用的AMR（AdaptiveMultiRate）編碼標準及ITU-T（InternationalmunicationUnion）制定的G.7**系列編碼標準等AMR：是語音編碼的一種音頻數(shù)據(jù)壓縮優(yōu)化方案，目前廣泛用于GERAN和UTRAN網(wǎng)絡(luò)。AMR編碼包括AMR-WB（AdaptiveMultiRateWideBand）和AMR-NB（AdaptiveMultiRateNarrowBand）兩種語音編碼方式，G.711：也稱為PCM（PulseCodeModulation），主要用于電話，支持64kbps的編碼速率。G.729：編解碼器具有很高的語音質(zhì)量和很低的延時，被廣泛地應(yīng)用在數(shù)據(jù)通信的各個領(lǐng)域，支持的編碼速率為8kbps。

AMR-NB有8種語音編碼率：AMR-NB：SID(39/0/0)、12.2(81/103/60)、10.2(65/99/40)、7.95(75/84/0)、7.4(61/87/0)、6.7(58/76/0)、5.15(49/54/0)、4.75(42/53/0)AMR-WB有9中語音編碼率：AMR-WB：23.85(72/405/0)、23.05(72/389)、19.85(72/325)、18.25(72/293)、15.85(72/245)、14.25(72/213)、12.65(72/181)、8.85(64/113)、6.6(54/78)

資費第一章第三章第四章VoLTE如何學(xué)習(xí)VoLTE主要流程VoLTE技術(shù)要點第五章VoLTE幾個案例第二章VoLTE新業(yè)務(wù)請求與響應(yīng)請求消息消息含義INVITE發(fā)起會話請求，邀請用戶加入一個會話，會話描述含于消息體中。對于兩方呼叫來說，主叫方在會話描述中指示其能夠接受的媒體類型及其參數(shù)。被叫方必需在成功響應(yīng)消息的消息體中指明其希望接受哪些媒體，還可以指示其行將發(fā)送的媒體。如果收到的是關(guān)于參加會議的邀請，被叫方可以根據(jù)Call-ID或者會話描述中的標識確定用戶已經(jīng)加入該會議，并返回成功響應(yīng)消息。ACK證實已收到對于INVITE請求的最終響應(yīng)。該消息僅和INVITE消息配套使用。BYE結(jié)束會話CANCEL取消尚未完成的請求，對于已完成的請求（即已收到最終響應(yīng)的請求）則沒有影響REGISTER注冊O(shè)PTIONS查詢服務(wù)器的能力序號狀態(tài)碼消息功能1xx臨時響應(yīng)表示已經(jīng)接收到請求消息，正在對其進行處理2xx成功響應(yīng)表示請求已經(jīng)被成功接受、處理3xx重定向響應(yīng)表示需要采取進一步動作，以完成該請求4xx客戶端出錯表示請求消息中包含語法錯誤或者SIP服務(wù)器不能完成對該請求消息的處理5xx服務(wù)器端出錯表示SIP服務(wù)器故障不能完成對正確消息的處理6xx全局錯誤表示請求不能在任何SIP服務(wù)器上實現(xiàn)注冊-目的注冊過程注冊是將UE的IP地址和IMPU的綁定關(guān)系存儲到到IMS系統(tǒng)中。注冊包括UE和網(wǎng)絡(luò)的雙向認證過程IMS用戶擁有兩種用戶標識：私有標識(IMPI：IMPrivateIdentity也稱PVI（PrivateUserID）)和公有標識(IMPU：IMPublicIdentity也稱PUI（PublicUserID）)：IMPI是歸屬網(wǎng)絡(luò)運營商提供給用戶的唯一全球標識，可以在歸屬網(wǎng)絡(luò)中從網(wǎng)絡(luò)角度標識用戶簽約數(shù)據(jù)。IMPI在所有注冊請求消息中使用，由UE傳送給網(wǎng)絡(luò)，用于注冊、授權(quán)、管理和計費等目的。IMPI的功能類似于IMSI在GSM中的功能，其對用戶而言是不可知的，僅僅存儲在智能卡中，只用于簽約標識和鑒權(quán)目的，不用于SIP請求的路由。其格式為。公共用戶標識是用于用戶間進行通信的標識。歸屬網(wǎng)絡(luò)運營商會給用戶分配一個或者多個IMPU。IMPU的功能類似于GSM中的MSISDN，在IMS中，IMPU用于路由SIP信令。IMPU可以采用SIPURI（sip：）或TELURI（tel:）格式注冊-目的IMS用戶擁有兩種用戶標識：IMPU和IMPI之間為多對多的關(guān)系即存在一機多號和一號多機。但對每一個VoLTE用戶而言，運營商會為其分配一個或者多個公共用戶標識和一個私有用戶標識。隱式注冊：由于IMS用戶的IMPI和IMPU之間可能存在多對多的關(guān)系。為簡化流程，提高注冊效率，采用了隱式注冊的方式。在HSS中為用戶定義了多個隱式注冊集。當(dāng)一個IMPI關(guān)聯(lián)多個IMPU，且多個IMPU處于相同的隱式注冊集中時，只要有其中的一個IMPU進行了一次IMS注冊，那么該IMPU所在的隱式注冊集中其他所有IMPU就同時完成注冊。這就是隱式注冊。注冊-涉及網(wǎng)元CSCF：為呼叫會話控制單元，又分為P-CSCF、I-CSCF、S-CSCF。HSS：為歸屬用戶服務(wù)器，存儲IMS用戶的簽約數(shù)據(jù)以及無線用戶的鑒權(quán)五元組等DNS：負責(zé)URI地址到IP地址的解析，在IMS網(wǎng)絡(luò)中負責(zé)將歸屬網(wǎng)絡(luò)（I-CSCF）的SIPURI轉(zhuǎn)換成歸屬網(wǎng)絡(luò)的IP地址。AS(ApplicationServer)：為IMS用戶提供增值業(yè)務(wù)。注冊流程第一次注冊請求和相應(yīng)：從HSS中取鑒權(quán)（AV）向量，實現(xiàn)手機對網(wǎng)絡(luò)校驗。鑒權(quán)五元組：IK/CK/AUTN/RAND/XRES保留XRES用于網(wǎng)絡(luò)對手機校驗：IK/CK/AUTN/RANDIK/CK/AUTN/RAND保留IK/CK：AUTN/RAND發(fā)送UE，用于UE對網(wǎng)絡(luò)的校驗第二次注冊請求和響應(yīng)：從HSS中取已經(jīng)注冊和未注冊的IMPU，以及相應(yīng)的計費信息，并進行網(wǎng)絡(luò)對手機的校驗。UE將RAND和共享密鑰計算RES，并發(fā)出將UE計算的RES和XRES對比，實現(xiàn)網(wǎng)絡(luò)對手機的校驗注冊-Register網(wǎng)絡(luò)歸屬域域名注冊用戶的公共身份標識注冊用戶的私有身份標識UE的IP和端口（SIP信令承載QCI=5的地址）頭字段限定一個請求消息在到達目的地之前允許經(jīng)過的最大跳數(shù)。它包含一個整數(shù)值，每經(jīng)過一跳，這個值就被減一。如果在請求消息到達目的地之前該值變?yōu)榱悖敲凑埱髮⒈痪芙^并返回一個483（跳數(shù)過多）錯誤響應(yīng)消息。這個是下一跳地址，對于空口信令而言，這個就是P-CSCF的地址十六進制：前五位是PLMN，中間4位是TAC，最后7位是cellIdentity標記用戶請求的注冊時長。單位：s。注意：該值為0時候表示是注銷注冊From：發(fā)起方的公共身份標識To：被叫方的公共身份標識在注冊請求中，To字段填充和from一樣注冊-Unauthorized401用于標識事務(wù)及對事務(wù)排序，前面是事務(wù)編號，后面是請求類型，同一個事務(wù)過程編號不變會話標識，整個會話過程不變注冊-Register第二次Path:與401之前Register消息保持一致P-Visited-Network-ID：與401之前Register消息保持一致VIA：與401之前Register消息保持一致From:與401之前Register消息保持一致Contact:與401之前Register消息保持一致Expires:與401之前Register消息保持一致Authorization:response參數(shù)為用戶根據(jù)密鑰和服務(wù)器提供的nonce值按MD5算法計算出的鑒權(quán)響應(yīng)值注冊-200OK隱式注冊集列表，這里表示的是一機一號標識頭域，存在+g.3gpp.atcf則表示是eSRVCC用戶的注冊。ATCF是eSRVCC的信令面錨定網(wǎng)元。實際生效的注冊時長。超時后需要重新注冊，對于長時在線呼叫的UE，呼叫失敗時可以回找最近一次register的時間差是否超出該時間在網(wǎng)元S-CSCF中關(guān)于注冊時長有最大，最小，默認三個設(shè)置值：最小注冊時長：S-CSCF允許的注冊最小時長。當(dāng)用戶注冊時所攜帶的注冊超時的時間小于這個值時，S-CSCF以423（TooBrief）響應(yīng)拒絕此注冊請求。最大注冊時長：S-CSCF允許的注冊最大時長，當(dāng)用戶注冊時所攜帶的注冊超時的時間大于這個值時，S-CSCF根據(jù)這個參數(shù)來修改UE的注冊時間。默認注冊時長：S-CSCF允許的注冊缺省時長，用于定義注冊請求中沒有攜帶Expires時的默認注冊時間。事件通告機制定義：所謂事件通告機制是指網(wǎng)絡(luò)中的一些實體可以訂閱網(wǎng)絡(luò)中某些資源或呼叫的狀態(tài)信息，當(dāng)那些被訂閱的資源的狀態(tài)發(fā)生改變時，負責(zé)這一資源的網(wǎng)絡(luò)實體將向訂閱者發(fā)送通告，通報當(dāng)前資源狀態(tài)的變化情況。實現(xiàn)：為了實現(xiàn)這一機制，因特網(wǎng)工程任務(wù)組(IETF)的SIP工作組對基本的會話啟動協(xié)議進行了擴充，提出了基于會話啟動協(xié)議的事件通告機制規(guī)范：RFC3265[1]。在規(guī)范中定義了兩個擴展方法：訂閱(SUBSCRIBE)和通告(NOTIFY)。SUBSCRIBE方法用于發(fā)起訂閱請求，NOTIFY方法用于通告當(dāng)前資源狀態(tài)。目的：實現(xiàn)增值業(yè)務(wù)。應(yīng)用于如自動回叫、在席、代答等多種富有市場前景的增值業(yè)。(1)訂閱者（UE）

訂閱者負責(zé)接收NOTIFY消息的會話啟動協(xié)議用戶代理(SIPUA)[2]。這些NOTIFY消息中包含訂閱者訂閱的資源信息。訂閱者典型的動作是向通告者發(fā)送SUBSCRIBE消息以請求創(chuàng)建一次訂閱關(guān)系。

(2)通告者（IMS網(wǎng)元P-CSCF）

通告者負責(zé)產(chǎn)生NOTIFY請求的SIPUA。通告者在NOTIFY消息中向訂閱者回饋當(dāng)前資源的狀態(tài)。通告者典型的動作是接收SUBSCRIBE消息并創(chuàng)建相應(yīng)的訂閱關(guān)系。

事件通告機制-subscribeSUBSCRIBE請求通過2XX響應(yīng)確認。不同的2XX響應(yīng)具有不同的語義：

(1)200OK表示訂閱已被接受且用戶已被授權(quán)訂閱請求的資源。

(2)202Accepted(接受)是事件通知機制擴展的響應(yīng)碼，表示訂閱請求已被理解，但是否授權(quán)給訂閱者未確定。如果返回非2XX響應(yīng)，則表示訂閱失敗，將沒有后繼的NOTIFY消息。比如：1、返回489BadEvent，表示通告者無法理解Event頭部；2、返回423Intervaltoosmall”(時間間隔太短)響應(yīng)，表示提出的訂閱時長太短，即（0<expiresSUBSCRIBE<1hour)&&(0<expiresSUBSCRIBE<Min通告者-config)，其中，Min通告者-config為通告者最小配置訂閱時長，為網(wǎng)絡(luò)側(cè)配置值

EVENT頭部，表明本次訂閱的事件類型UE期望的訂閱時長網(wǎng)絡(luò)實際允許的訂閱時長事件通告機制-notify與訂閱相關(guān)的信息由NOTIFY消息傳送。通告者在成功創(chuàng)建訂閱關(guān)系后，必須立即發(fā)送NOTIFY消息，向訂閱者通告當(dāng)前訂閱資源的狀態(tài)。通告者使用SUBSCRIBE消息中Accept頭部明確允許的或者Event頭部隱含指明的消息體格式將資源的狀態(tài)信息或指向該資源狀態(tài)的URI封裝在消息中。消息也可包含擴展的Allowed-Events頭部，指示本節(jié)點能夠支持的事件包類型。NOTIFY消息中必須包含擴展的Subscription-State頭部，指示創(chuàng)建的訂閱的狀態(tài)。共有3種訂閱狀態(tài)，分別是：(1)active：訂閱已被接受且授權(quán)成功。

(2)pending：SUBSCRIBE請求已收到，但還沒有足夠的信息決定接受或拒絕此次訂閱。但頭部會包含reason參數(shù)指示訂閱被終止的原因，或者包含Retry-After參數(shù)，指示訂閱者過一段時間后重新發(fā)起訂閱請求。

(3)terminated：訂閱未激活，或創(chuàng)建的訂閱關(guān)系終止。訂閱結(jié)果呼叫-呼叫過程的sip信令干了啥？呼叫過程的SIP信令干了三件事1、打通從主叫UE到被叫UE的路由通道2、雙方進行媒體協(xié)商3、雙方進行資源預(yù)留并確認呼叫-打通路由INVITESIP/2.0Via:SIP/2.0/UDP04:5060;branch=z9hG4bKc71arac22az654br2d4b45czh;Role=2;Dpt=75f4_16;sc=2-a;TRC=a01-ffffffff,SIP/2.0/UDP02:5060;branch=z9hG4bK676ehbdcgcacfzchgebhr7d52;Role=2;Dpt=75f2_16,SIP/2.0/UDP3:12641;branch=z9hG4bK9e3f66a99503c8d7aa4f4eb1bb8f73a5;rport=12641Route:<sip:18:6801;lr>,<sip:04;lr;ORGDLGID=2c-2-1;Dpt=75f4_6;TRC=a01-ffffffff>Record-Route:<sip:04;lr;Role=2;Dpt=75f4_216;X-zteCsfCookie=5;TRC=a01-ffffffff>,<sip:02;transport=udp;lr;Role=2;Dpt=75f2_116;X-zteCsfCookie=4;TRC=a01-ffffffff>Call-ID:sbc9e3f66a99503c8d7aa4f4eb1bb8f73a5From:<>;tag=9e3f66a99503c8d7aa4f4eb1bb8f73a5To:<>CSeq:60407INVITEAllow:INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,REFER,MESSAGEContact:<sip:3:12641;transport=udp>Max-Forwards:68Require:preconditionSupported:100relSession-Expires:600Privacy:noneP-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11;"location-info=3"P-Asserted-Identity:<>,<tel:>Min-SE:600P-Charging-Vector:icid-value="78f32f819e10cf148de3d7af70c5142e.3485362059.13.12"Served-Party-IP-Address:3ViaSCSCF1addressPCSCF1addressUEaddressS-CSCF處理第一個INVITE消息

UEP-CSCFS-CSCFASI-CSCFS-CSCFASP-CSCFUE3.INVITE4.100Trying5.INVITE6.100Trying7.INVITE8.100Trying9.INVITE

10.INVITE11.100Trying12.100Trying

13.INVITE

14.100Trying

15.INVITE

16.100Trying

17.INVITE

18.100Trying

19.INVITE

20.183會話進行中

SDP應(yīng)答1

21.183會話進行中

22.183會話進行中

23.183會話進行中

24.183會話進行中

25.183會話進行中

26.183會話進行中

27.183會話進行中28.PRACK(SDP提供2)

29.PRACK

30.PRACK

31.PRACK

32.PRACK

33.PRACK

34.PRACK

35.PRACK

36.PRACK資源預(yù)留資源預(yù)留

37.200OK

38.200OK

39.200OK

40.200OK

41.200OK

44.200OK

45.200OK

42.200OK

43.200OK2.100Trying1.INVITE（SDP提供1）呼叫

SDP應(yīng)答2

UEP-CSCFS-CSCFASI-CSCFS-CSCFASP-CSCFUE呼叫1.UPDATE(SDP提供3)

2.UPDATE

3.UPDATE

4.UPDATE

5.UPDATE

6.UPDATE

7.UPDATE

8.UPDATE

9.UPDATE

10.200(OK)

11.200(OK)

12.200(OK)

13.200(OK)

14.200(OK)

15.200(OK)

16.200(OK)

17.200(OK)

18.200(OK)

19.180(RING)

20.180(RING)

21.180(RING)

22.180(RING)

23.180(RING)

25.180(RING)

26.180(RING)

27.180(RING)

28.180(RING)

29.PRACK

24.180(RING)

30.PRACK

31.PRACK

32.PRACK

33.PRACK

34.PRACK

35.PRACK

36.PRACK

37.PRACK

SDP應(yīng)答3

UEP-CSCFS-CSCFASI-CSCFS-CSCFASP-CSCFUE呼叫

1.200(OK)

2.200(OK)

3.200(OK)

4.200(OK)

5.200(OK)

6.200(OK)

7.200(OK)

8.200(OK)

9.200(OK)

10.200(OK)

11.200(OK)

12.200(OK)

13.200(OK)

14.200(OK)

15.200(OK)

16.200(OK)

17.200(OK)

18.200(OK)

19.200(OK)

20.ACK

21.ACK

22.ACK

23.ACK

24.ACK

25.ACK

26.ACK

27.ACK

28.ACK

29.ACK請求與響應(yīng)100（Trying）INVITE請求的重傳和100響應(yīng)：主叫方呼叫被叫方通過INVITE請求與被叫建立多媒體會話。主叫UE發(fā)出INVITE請求并設(shè)定定時器，等待被叫UE的響應(yīng)，如定時器超時，需要重傳一個INVITE請求。為保證UE不會頻繁的重發(fā)INVITE消息，重傳機制設(shè)定為消息發(fā)往的下一個網(wǎng)元向上一個網(wǎng)元回100響應(yīng)，由下一個網(wǎng)元負責(zé)重傳INVITE請求。I-CSCF只做消息轉(zhuǎn)發(fā)，不負責(zé)重傳INVITE消息。183響應(yīng)被叫UE返回的183響應(yīng)：被叫UE返回183響應(yīng)（會話進行中）表明會話建立過程已經(jīng)啟動，被叫已經(jīng)收到。PRACK請求主叫方的PRACK請求：主叫方PRACK請求的作用：為保證被叫方了解主叫方已經(jīng)收到其發(fā)送的臨時183、180響應(yīng)（會話進行中），需要主叫方發(fā)送確認消息。ACK和PRACK的區(qū)別（1）ACK是響應(yīng)，只有INVITE請求存在ACK響應(yīng)。（2）PRACK是請求而非響應(yīng)，是對臨時響應(yīng)的確認，由于PRACK為請求，因此被叫方收到該請求后，需要發(fā)送200（OK）響應(yīng)。第一個網(wǎng)元的臨時響應(yīng)被叫收到呼叫請求的響應(yīng)被叫振鈴響應(yīng)本次呼叫受理成功的響應(yīng)本次invite的最終響應(yīng)響應(yīng)目的的請求，確認183消息已收到響應(yīng)目的的請求，確認180消息已收到請求確認請求確認相互通知資源預(yù)留完成媒體協(xié)商與資源預(yù)留（SDP）主叫啟動資源預(yù)留,并通知被叫主叫UE被叫UEINVITE（第一個SDP提供：所希望媒體類型與所有編碼方案）183會話進行中（第一個SDP應(yīng)答：支持的媒體類型及編碼方案PRACK（第二個SDP提供：雙方協(xié)商的媒體類型和編碼方案）200OK(第二個SDP應(yīng)答：對所協(xié)商媒體類型和編碼方案的確認)被叫啟動資源預(yù)留,并通知主叫UPDATE（第三個SDP提供：表明主叫資源預(yù)留完成）200OK（第三個SDP應(yīng)答：表明被叫資源預(yù)留完成）資源預(yù)留：為保證雙方所協(xié)商的媒體會話可以建立，空口需要為主叫和被叫用戶分配資源，在資源被成功預(yù)留之前，不能保證媒體會話可以建立。一般情況下進行SDP提供/應(yīng)答的協(xié)商確定了媒體格式和編碼方式后可進行資源預(yù)留。媒體協(xié)商：主叫和被叫UE在會話的建立過程中需要對媒體的類型和編碼方式達成一致，為此使用SDP請求和應(yīng)答機制對媒體進行協(xié)商。雙方所協(xié)商的媒體類型包括視頻、音頻、文本、聊天等。每種媒體類型包括多種編碼方式，如音頻包括PCMU、G.726編碼、AMR-WB（自適應(yīng)多速率寬帶）編碼等。視頻包括MPV、H.262編碼等。雙方需要協(xié)商都支持的媒體類型以及所使用的編碼方式。INVITE-request消息起始行SIP消息頭域SIP消息體（SDP）INVITE-request-消息頭域SIP頭備注From

To

Call-ID標識對話CSeq標識事務(wù)，以及標識同一對話中請求消息的先后順序Via記錄請求消息路徑，用于響應(yīng)消息路由Max-Forwards限制消息最大轉(zhuǎn)發(fā)次數(shù)右表為消息頭域必選參數(shù)，為減少網(wǎng)絡(luò)資源開銷，應(yīng)盡量避免在SIP消息中攜帶不必要的頭域用戶終端和信任的代理之間傳輸用戶信息的標示攜帶支持的能力擴展。100rel值表示支持1XX響應(yīng)的可靠傳輸是否支持放音提示用于協(xié)商會話刷新時間，用戶雙方確認會話存活與否，實際會話將在Session-Expires/2的時間進行會話更新。會話刷新的最小時間間隔，最小值是90，如果不存在，則為默認值90要求對方一定支持的特性。安全認證。（SecurityMechanismAgreement）要求代理一定支持的特性協(xié)商SIP的安全機制發(fā)起請求的終端信息標志了發(fā)給對方的消息體的媒體類型INVITE-request-消息體SIP攜帶SDP，用于媒體協(xié)商；SIP攜帶XML，用于攜帶格式化的信息，如訂閱事件通知；SIP攜帶CPIM，用于即時消息v：描述SDP協(xié)議版本，通常取值為“0”o：表示會話源（會話所有者）信息，同時攜帶會話標識s：表示會話類型c：表示媒體地址信息，即發(fā)送和接受媒體流的地址b：給出會話或媒體所用帶寬，單位為kbit/s.修飾語b=AS應(yīng)用特定最大帶寬，表示一個地點單一媒體帶寬b=RR表示分配給活動數(shù)據(jù)的RTCP帶寬b=RS表示RTCP分配給其他參與者的RTP會話帶寬t：會話開始和結(jié)束時間，VoLTE里面一般都缺省0，不做時間控制m：描述媒體類型、媒體端口號、傳輸協(xié)議、格式列表a：對會話或媒體的附加屬性進行描述。a=rtpmap：凈荷類型號、編碼名、時鐘速率、編碼參數(shù)a=fmtp：指定格式的附加參數(shù)a=ptime：媒體分組打包的時長。通話雙方的codecptime值一定要相同，譬如G711，有20msptime和5msptime等a=maxptime：不管何種媒體格式，媒體分組打包時長最大值a=inactive（recvonly、sendrecv、sendonly）a=cur：當(dāng)前狀態(tài)：預(yù)置處理類型、狀態(tài)類型、方向

如此例：本端當(dāng)前qos資源還未預(yù)留、遠端當(dāng)前qos資源還未預(yù)留a=des：期望狀態(tài)：預(yù)置處理類型、強度標識、狀態(tài)類型、方向

如此例：本端期望的預(yù)留資源是高強度的雙向預(yù)留資源、遠端期望的預(yù)留資源是強度可選的雙向預(yù)留資源INVITE-183表示該臨時應(yīng)答需要支持可靠傳輸。SIP實體及終端的特性能力PRACKRack頭部使用在PRACK請求的中用于支持可靠臨時應(yīng)答。Rack取值包括兩個數(shù)字和一個消息方法名：第一個數(shù)字取值與PRACK對應(yīng)的1xx響應(yīng)消息中Rseq取值相同；第二個數(shù)字和消息方法名與1xx消息對應(yīng)的請求消息中Cseq取值相同UPDATE這個與原始請求里面的設(shè)置變化因為字段c的內(nèi)容根據(jù)協(xié)商變化了媒體協(xié)商一致兩部分內(nèi)容一樣UPDATE200OKRinging180表示該臨時應(yīng)答需要支持可靠傳輸。PRACKPRACK200OKINVITE200OKTimer表示必須支持會話更新前面數(shù)字表示會話更新時間參數(shù)，實際會話將在Session-Expires/2的時間進行會話更新。Refresher表明會話更新的執(zhí)行者是：UAC即用戶代理客戶端。1、如果在間隔時間內(nèi)沒收到會話更新請求，用戶代理會發(fā)送bye移除會話。2、當(dāng)Session-Expires的間隔太小（小于UAS所支持的Min-SE頭字段的值）時，UAS將回應(yīng)422代碼要求UAC重新協(xié)商。語音承載QCI=1的建立與修改語音承載QCI=1的建立與修改呼叫釋放1、SIP是承載在QCI=1的SIP信令專用承載；而呼叫結(jié)束時釋放的是語音QCI=1的承載，相互之間無任何影響，所以這里BYE200OK的位置都是正常的。2、如果在SIP的BYE200OK時候，語音QCI=5的承載沒有釋放，或者釋放異常，下次呼叫會失敗。eSRVCC切換第一章第三章第四章VoLTE如何學(xué)習(xí)VoLTE主要流程VoLTE技術(shù)要點第五章VoLTE幾個案例第二章VoLTE新業(yè)務(wù)LTE網(wǎng)絡(luò)和VoLTE終端如何相互通知對方具備VoLTE能力？（一）終端在注冊的時候attachreqeust會告訴網(wǎng)絡(luò)終端是否支持IMS

voice_domain_pref

length=1(0x1)

UE_usage_setting=0(0x0)(Voicecentric)

voice_domain_pref_for_EUTRAN=3(0x3)(IMSPSVoicepreferred,CSVoiceassecondary)3GPP24.301（NAS）和24.008VoicedomainpreferenceandUE'susagesettingvalue(octet3,bit1to3)

UE'susagesetting(1bitfield)

Bit3

0

Voicecentric1

Datacentric

VoicedomainpreferenceforE-UTRAN(2bitfield)

Bit21

00

CSVoiceonly01

IMSPSVoiceonly10

CSvoicepreferred,IMSPSVoiceassecondary11

IMSPSvoicepreferred,CSVoiceassecondary

MSnotsupportingIMSvoiceshallind