VoLTE原理簡(jiǎn)介

項(xiàng)目名稱
文檔編號(hào)
版 本 號(hào)
部 門	專業(yè)服務(wù)部
作 者

版權(quán)所有
大唐移動(dòng)通信設(shè)備有限公司


本資料及其包含的所有內(nèi)容為大唐移動(dòng)通信設(shè)備有限公司(大唐移動(dòng))所有,受中國(guó)法律及適用之國(guó)際公約中有關(guān)著作權(quán)法律的保護(hù)。未經(jīng)大唐移動(dòng)書面授權(quán)，任何人不得以任何形式復(fù)制、傳播、散布、改動(dòng)或以其它方式使用本資料的部分或全部?jī)?nèi)容，違者將被依法追究責(zé)任。
文檔更新記錄

日期	更新人	版本	備注
2014-11-19	蘇曉群	1.0.0	創(chuàng)建文檔
2014-12-14	蘇曉群	1.0.1	呼叫信令流程更新為改進(jìn)后的流程

目錄
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072461]1
引言... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072462]1.1 編寫目的... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072463]1.2預(yù)期讀者和閱讀建議... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072464]1.3參考資料... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072465]2
VOLTE原理介紹... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072466]2.1VOLTE介紹... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072467]2.1.1技術(shù)背景... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072468]2.1.2技術(shù)優(yōu)勢(shì)... 4[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072469]2.2VOLTE系統(tǒng)架構(gòu)... 5[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072470]2.3VOLTE關(guān)鍵技術(shù)... 6[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072471]2.3.1無(wú)線承載Qos等級(jí)標(biāo)識(shí)
（譯成中文，李）... 6[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072472]2.3.2 AMR-WB語(yǔ)音編碼... 7[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072473]2.3.3 SIP(Session Initiation Protocol)&SDP. 8[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072474]2.3.4RoHC健壯性報(bào)頭壓縮協(xié)議... 10[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072475]2.3.5SPS半持續(xù)調(diào)度... 11[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072476]2.3.6 eSRVCC(Enhanced Single Radio Voice Call Continuity)
11[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072477]3
VOLTE KPI分類及定義... 13[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072478]4
VOLTE信令流程... 15[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072479]4.1注冊(cè)流程及重要信令詳解... 15[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072480]4.1.1 Activate Default EPS Bearer Context Request（QCI=5）... 17[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072481]4.1.2 REGISTER(1ST Sip Register Request)& REGISTER 401（Unauthorized）... 18[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072482]4.1.3 REGISTER(2nd Sip Register Request)& REGISTER 200. 19[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072483]4.1.4 SUBSCRIBE& NOTIFY.. 20[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072484]4.2語(yǔ)音通話流程及重要信令詳解... 22[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072485]4.2.1 INVITE.. 24[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072486]4.2.2 RRCConnectionReconfiguration （QCI=1）... 25[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072487]4.2.3UPDATE & UPDATE 200. 26[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072488]4.2.4視頻通話流程與語(yǔ)音通話流程的異同... 27[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072489]4.3eSRVCC切換及重要信令詳解... 30[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072490]4.3.1AttachRequest& Initial Context Setup Request
32[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072491]5
常見問(wèn)題案例... 34[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072492]6.1SIM卡無(wú)VoLTE權(quán)限導(dǎo)致注冊(cè)失敗... 34[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072493]6.2 SIM授權(quán)問(wèn)題導(dǎo)致eSRVCC無(wú)法執(zhí)行... 35[/url]
[url=file:///C:/Users/lenovo/Desktop/VOLTE%E5%8E%9F%E7%90%86%E7%AE%80%E4%BB%8B.docx#_Toc420072494]6.3廣東云浮項(xiàng)目呼叫建立時(shí)延過(guò)長(zhǎng)... 39[/url]



1
引言
1.1 編寫目的

本文主要對(duì)VOLTE的原理進(jìn)行介紹，并對(duì)VOLTE小區(qū)主要參數(shù)配置及測(cè)試信令進(jìn)行詳細(xì)說(shuō)明，使讀者對(duì)VOLTE有個(gè)基本的了解；由于VOLTE現(xiàn)在未商用，所以實(shí)際優(yōu)化經(jīng)驗(yàn)較少，優(yōu)化可以參考R9及2/3G的優(yōu)化經(jīng)驗(yàn)。

1.2預(yù)期讀者和閱讀建議

本文檔預(yù)期讀者為網(wǎng)絡(luò)技術(shù)優(yōu)化人員、系統(tǒng)測(cè)試人員等。

1.3參考資料[1]
《TD-LTE半持續(xù)調(diào)度特性實(shí)現(xiàn)報(bào)告》
[2]
3GPP TS 23.216Single Radio Voice Call Continuity (SRVCC)
[3]IETF RFC 3261 Session Initiation Protocol
[4]IR.92 -IMS Profile for Voice and SMS
[5]《中國(guó)移動(dòng)VoLTE總體建設(shè)方案》—移動(dòng)集團(tuán)設(shè)計(jì)院
2
VOLTE原理介紹
2.1VOLTE介紹
2.1.1技術(shù)背景
目前業(yè)界對(duì)LTE語(yǔ)音的解決方案有三種，分別是VOLTE、CSFB、SGLTE， VOLTE與CSFB是3GPP標(biāo)準(zhǔn)化方案，SGLTE為終端實(shí)現(xiàn)方案，其中VOLTE是移動(dòng)4G語(yǔ)音解決方案的終極方案；SGLTE不需要對(duì)網(wǎng)絡(luò)進(jìn)行改動(dòng)，VOLTE與CSFB均需對(duì)網(wǎng)絡(luò)進(jìn)行改造。
VOLTE是什么？最直接簡(jiǎn)單的理解就是VOIP，只是網(wǎng)絡(luò)的承載體由互聯(lián)網(wǎng)變成了LTE，同時(shí)在LTE的業(yè)務(wù)中給了一個(gè)高優(yōu)先級(jí)保證QOS。
VoLTE是GSMA IR 92定義的標(biāo)準(zhǔn)LTE語(yǔ)音解決方案，最大的網(wǎng)絡(luò)改動(dòng)就是引入IMS網(wǎng)絡(luò)，由IMS配合LTE和EPC網(wǎng)絡(luò)實(shí)現(xiàn)端到端的基于分組域的語(yǔ)音、視頻通信業(yè)務(wù)。通過(guò)IMS系統(tǒng)的控制，VoLTE解決方案可以提供和電路域性能相當(dāng)?shù)恼Z(yǔ)音業(yè)務(wù)及其補(bǔ)充業(yè)務(wù)，包括號(hào)碼顯示、呼叫轉(zhuǎn)移、呼叫等待、會(huì)議電話等。
2.1.2技術(shù)優(yōu)勢(shì)
VoLTE開啟了向移動(dòng)寬帶語(yǔ)音演進(jìn)之路，其給運(yùn)營(yíng)商帶來(lái)兩方面的價(jià)值，一是提升無(wú)線頻譜利用率、降低網(wǎng)絡(luò)成本。LTE的頻譜利用效率GSM的4倍以上。另一個(gè)價(jià)值就是提升用戶體驗(yàn)，VoLTE的體驗(yàn)明顯優(yōu)于傳統(tǒng)CS語(yǔ)音。首先，高清語(yǔ)音和視頻編解碼的引入顯著提高了通信質(zhì)量；其次，VoLTE的呼叫接續(xù)時(shí)長(zhǎng)大幅縮短，VoLTE比CS呼叫縮短一半以上。
下面是實(shí)際測(cè)試的一些指標(biāo)：
呼叫建立時(shí)延更短：第一條隨機(jī)接入消息到終端接收到網(wǎng)絡(luò)側(cè)下發(fā)的SIP 180 Ring消息之間的時(shí)間差，在外場(chǎng)短呼測(cè)試中看到平均時(shí)延為2S左右，而2G時(shí)代在6-7秒，用戶感知為秒通。
語(yǔ)音質(zhì)量更高：因?yàn)槭褂?3.85K寬帶AMR技術(shù)，語(yǔ)音質(zhì)量相比2G、3G語(yǔ)音質(zhì)量有質(zhì)的提高，在外場(chǎng)測(cè)試時(shí)，在好點(diǎn)MOS值在4.1左右，而3G MOS值在3.0—3.5之間，在同一地點(diǎn)的OTT語(yǔ)音在3.5左右（無(wú)線資源不受限）。對(duì)運(yùn)營(yíng)商來(lái)說(shuō)在這一點(diǎn)上體現(xiàn)了移動(dòng)網(wǎng)絡(luò)相對(duì)于OTT的優(yōu)勢(shì)。
系統(tǒng)間切換方面使用eSRVCC切換，測(cè)試切換時(shí)延在150MS以內(nèi)，對(duì)用戶感知無(wú)影響，且切換成功率高。
視頻質(zhì)量更好：在同一地點(diǎn)，視頻通話的圖像遠(yuǎn)比OTT視頻通話的圖像清晰。

	VOLTE	2G/3G
呼叫時(shí)延	0.5-2 s	5-8 s
語(yǔ)音質(zhì)量	頻率：50~7000Hz 編解碼：AMR-WB 23.85Kbps	頻率：300~3400Hz 編解碼：AMR-NB 12.2Kbps
視頻質(zhì)量	典型分辨率：480*640 720P/1080P possible	分辨率：176*144
頻譜效率	仿真測(cè)試結(jié)果顯示：同樣承載AMR，LTE的頻譜效率可達(dá)到R993倍以上

2.2VOLTE系統(tǒng)架構(gòu)
VOLTE采用IMS作為業(yè)務(wù)控制層系統(tǒng)，EPC僅作為承載層；要求終端、無(wú)線網(wǎng)絡(luò)、分組域、電路域和IMS域端到端的技術(shù)配合以實(shí)現(xiàn)基于IMS的分組域語(yǔ)音和多媒體業(yè)務(wù)。SRVCC切換解決了語(yǔ)音連續(xù)性問(wèn)題，呼叫時(shí)延短，無(wú)需回落2G/3G發(fā)起語(yǔ)音，避免頻繁網(wǎng)間重選。VOTLE網(wǎng)絡(luò)框架圖如下：

中移動(dòng)二階段VOLTE福州測(cè)試的網(wǎng)絡(luò)拓樸如下：
VOLTE的協(xié)議架構(gòu)如下圖，從圖中可以看到，SIP協(xié)議只在終端和IMS支持，對(duì)于無(wú)線接入網(wǎng)只是一個(gè)透?jìng)髯鲇茫?/font>

2.3VOLTE關(guān)鍵技術(shù)
2.3.1無(wú)線承載Qos等級(jí)標(biāo)識(shí) （譯成中文，李）
EPS系統(tǒng)中，QoS控制的基本粒度是EPS承載(Bearer)，即相同承載上的所有數(shù)據(jù)流將獲得相同的QoS保障（如調(diào)度策略，緩沖隊(duì)列管理，鏈路層配置等），不同的QoS保障需要不同類型的EPS承載來(lái)提供，在接入網(wǎng)中，空口上承載的QoS是由eNodeB來(lái)控制的， 每個(gè)承載都有相應(yīng)的QoS參數(shù)QCI（QoS Class Identifier）。
根據(jù)QoS的不同， EPS Bear可以劃分為兩大類： GBR(Guranteed Bit Rate) 和 Non－GBR。所謂GBR，是指承載要求的比特速率被網(wǎng)絡(luò)“永久”恒定的分配，即使在網(wǎng)絡(luò)資源緊張的情況下，相應(yīng)的比特速率也能夠保持。MBR(Maximum Bit Rate)參數(shù)定義了GBR Bear在資源充足的條件下，能夠達(dá)到的速率上限。MBR的值有可能大于或等于GBR的值。相反的，Non－GBR指的是在網(wǎng)絡(luò)擁擠的情況下，業(yè)務(wù)（或者承載）需要承受降低速率的要求，由于Non－GBR承載不需要占用固定的網(wǎng)絡(luò)資源，因而可以長(zhǎng)時(shí)間地建立。而GBR承載一般只是在需要時(shí)才建立。
LTE中共有9種不同的QCI，在VOLTE業(yè)務(wù)中主要用到了QCI 1、QCI 2、QCI 5，而普通的數(shù)據(jù)業(yè)務(wù)主要是QCI 8/9。不同QCI列表如下圖，IMS信令使用QCI 5，語(yǔ)音業(yè)務(wù)共使用QCI 1、QCI5、QCI 8/9，視頻電話業(yè)務(wù)共使用QCI 1、QCI 2、QCI 5、QCI 8/9。

QCI	資源類型（Resource Type）	優(yōu)先級(jí)（Priority）	時(shí)延 （Packet Delay Budget）	丟包率（PacketError Loss ate）	典型業(yè)務(wù)（ExampleServices）
1	GBR	2	100 ms	10-2	VOIP
2		4	150 ms	10-3	電話會(huì)議, 會(huì)話視頻(直播流媒體)
3		3	50 ms	10-3	實(shí)時(shí)在線游戲, 實(shí)時(shí)工業(yè)監(jiān)控
4		5	300 ms	10-6	非會(huì)話視頻(緩沖流媒體)
5	Non-GBR	1	100 ms	10-6	IMS 信令
6		6	300 ms	10-6	視頻(緩沖流媒體)
7		7	100 ms	10-3	視頻(直播流媒體), 話音業(yè)務(wù)
				10-6	交互式游戲
8		8	300 ms	10-6	E-Mail, MSN, QQ, WWW P2P文件共享
9		9	300 ms	10-2

2.3.2AMR-WB語(yǔ)音編碼
AMR全稱AdaptiveMulti-Rate，自適應(yīng)多速率編碼，主要用于移動(dòng)設(shè)備的音頻，壓縮比比較大，但相對(duì)其他的壓縮格式質(zhì)量比較差，但主要用于人聲，所以效果較好。2/3使用的語(yǔ)音編碼格式為AMR-NB，語(yǔ)音帶寬范圍：300－3400Hz，8KHz采樣率，VoLTE使用AMR-WB編碼，提供語(yǔ)音帶寬范圍達(dá)到50～7000Hz，16KHz采樣率用戶可主觀感受到話音比以前更加自然、舒適和易于分辨。
AMR 一共有16種編碼方式， 0-7對(duì)應(yīng)8種不同的編碼方式， 8-15 用于噪音或者保留用。

Frame Type	Mode Indication	Mode Request	Frame content (AMR mode, comfort noise, or other)
0	0	0	AMR 4,75 kbit/s
1	1	1	AMR 5,15 kbit/s
2	2	2	AMR 5,90 kbit/s
3	3	3	AMR 6,70 kbit/s (PDC-EFR)
4	4	4	AMR 7,40 kbit/s (TDMA-EFR)
5	5	5	AMR 7,95 kbit/s
6	6	6	AMR 10,2 kbit/s
7	7	7	AMR 12,2 kbit/s (GSM-EFR)
8	-	-	AMR SID
9	-	-	GSM-EFR SID
10	-	-	TDMA-EFR SID
11	-	-	PDC-EFR SID
12-14	-	-	For future use
15	-	-	No Data (No transmission/No reception)

AMR-WB同樣也有16種語(yǔ)音編碼，目前主要使用2和8兩種

Frame Type Index	Mode Indication	Mode Request	Frame content (AMR-WB mode, comfort noise, or other)
0	0	0	AMR-WB 6.60 kbit/s
1	1	1	AMR-WB 8.85 kbit/s
2	2	2	AMR-WB 12.65 kbit/s
3	3	3	AMR-WB 14.25 kbit/s
4	4	4	AMR-WB 15.85 kbit/s
5	5	5	AMR-WB 18.25 kbit/s
6	6	6	AMR-WB 19.85 kbit/s
7	7	7	AMR-WB 23.05 kbit/s
8	8	8	AMR-WB 23.85 kbit/s
9	-	-	AMR-WB SID (Comfort Noise Frame)
10-13	-	-	For future use
14	-	-	speech lost
15	-	-	No Data (No transmission/No reception)

2.3.3SIP(Session Initiation Protocol)&SDP


SIP協(xié)議是互聯(lián)網(wǎng)行業(yè)標(biāo)準(zhǔn)組織IETF提出的，SIP(Session Initiation Protocol)是一個(gè)應(yīng)用層的信令控制協(xié)議。用于創(chuàng)建、修改和釋放一個(gè)或多個(gè)參與者的會(huì)話。這些會(huì)話可以是Internet多媒體會(huì)議、IP電話或多媒體分發(fā)。會(huì)話的參與者可以通過(guò)組播（multicast）、網(wǎng)狀單播（unicast）或兩者的混合體進(jìn)行通信。VoLTE選擇了SIP協(xié)議，最主要的原因就是免費(fèi)。

在VOLTE中引入了IMS，對(duì)VOLTE進(jìn)行業(yè)務(wù)控制，MME只是做為業(yè)務(wù)的承載體，IMS對(duì)業(yè)務(wù)的控制全部通過(guò)SIP消息完成，在學(xué)習(xí)VoLTE的過(guò)程中必須學(xué)習(xí)SIP消息。
SIP有兩種類型的消息，它們是：
（1）
請(qǐng)求：從客戶機(jī)發(fā)到服務(wù)器的消息。
（2）
響應(yīng)：從服務(wù)器發(fā)到客戶機(jī)的消息。
　其中VOLTE常用的請(qǐng)求消息包括下列幾種，表中也列出了消息的定義文檔：

SIP方法	描述	定義文檔
INVITE	表示一個(gè)客戶端發(fā)起或被邀請(qǐng)參加電話會(huì)議（indicates aclient is being invited to participate in a call session）	RFC3261
ACK	確認(rèn)客戶已經(jīng)收到一個(gè)INVITE請(qǐng)求的最終響應(yīng)（Confirms that the client has received a finalresponse to an INVITE request）	RFC3261
BYE	終止一個(gè)呼叫，可以由主叫或被叫方發(fā)起（Terminates a call and can be sent by calleror the callee）	RFC3261
OPTIONS	查詢服務(wù)器的能力（Queries the capabilities of servers）	RFC3261
CANCEL	取消所有正在處理中的請(qǐng)求（Cancel any pendingrequest）	RFC3261
REGISTER	向標(biāo)題字段中的SIP服務(wù)器發(fā)起地址列表注冊(cè)（Registers the address listed in the To headerfield with SIP Server）	RFC3261
PRACK	臨時(shí)確認(rèn)（Provisional acknowledgement）	RFC3262
SUBSCRIBE	向服務(wù)器訂閱某個(gè)事件通知（Subscribes for an Event of Notification fromthe Notifier）	RFC3265
NOTIFY	向訂閱都發(fā)送一個(gè)新的事件（Notify thesubscriber of a new Event）	RFC3265
UPDATE	在沒(méi)有修改對(duì)話狀態(tài)的情況下修改會(huì)話（Modifies the state of a session withoutchanging the state of the dialog）	RFC3311
PUBLISH	發(fā)布一個(gè)事件到服務(wù)器（Publishes an event to the Server）	RFC3903
INFO	會(huì)話過(guò)程中發(fā)送一個(gè)會(huì)話消息，但不修改會(huì)話狀態(tài)（Sendsmid-session information that does not modify the session state）	RFC6086
REFER	請(qǐng)求收件人發(fā)出SIP請(qǐng)求（Asks recipient to issue SIP request(call transfer)）	RFC3515
MESSAGE	使用SIP傳輸即時(shí)消息（Transports instant messages using SIP）	RFC3248

響應(yīng)消息包含數(shù)字響應(yīng)代碼，SIP響應(yīng)代碼集部分基于HTTP響應(yīng)代碼。
有兩種類型的響應(yīng)，它們是：

· 臨時(shí)響應(yīng)（1XX）：臨時(shí)響應(yīng)被服務(wù)器用來(lái)指示進(jìn)程，但是不終結(jié)SIP事物。

· 最終響應(yīng)（2XX，3XX，4XX，5XX，6XX）：最終響應(yīng)終止SIP事物。

1xx	進(jìn)展相應(yīng)	臨時(shí)相應(yīng)
2xx	成功	最終相應(yīng)
3xx	重定向錯(cuò)誤	最終相應(yīng)
4xx	客戶端錯(cuò)誤	最終相應(yīng)
5xx	服務(wù)端錯(cuò)誤	最終相應(yīng)
6xx	全局錯(cuò)誤	最終相應(yīng)

SIP由于是采用文本格式編碼，所以消息格式很簡(jiǎn)單，是由Message Header加可選的Message body構(gòu)成，Message Header 從第二行開始每一行都由“Tag :Valued”格式組成，每一行描述一個(gè)屬性，SDP也是用文本格式描述的，一個(gè)SDP Description可以包含很多行，每一行的格式如下：
Type = Value
Type只用一個(gè)字母來(lái)表示；一個(gè)SDP Description通常有一個(gè)Session-level和多個(gè)Media-level信息組成，常見的SDP屬性如下：

v	Protocol version
b	Bandwidthinformation
o	Ownerof the session and session identifier
z	Timezone adjustments
s	Nameof the session
k	Encryptionkey
i	Informationabout the session
a	Attributelines
u	URLcontaining a description of the session
t	Timewhen the session is active
e	E-mailaddress to obtain information about the session
r	Timeswhen the session will be repeated
p	Phonenumber to obtain information about the session
m	Medialine
c	Connectioninformation
i	Informationabout a media line

2.3.4RoHC健壯性報(bào)頭壓縮協(xié)議
在LTE中，為了在分組交換域(PS)提供語(yǔ)音業(yè)務(wù)且到達(dá)接近常規(guī)電路交換域的效率，必須對(duì)IP/UDP/RTP報(bào)頭進(jìn)行壓縮。對(duì)于話音數(shù)據(jù)包，其包長(zhǎng)較小，封裝成IP包后，采用頭壓縮技術(shù)能有效提高頻譜利用率，對(duì)于視頻業(yè)務(wù)數(shù)據(jù)包，同樣壓縮后也可以提高頻譜效率。在LTE系統(tǒng)中，規(guī)定PDCP子層支持健壯性報(bào)頭壓縮協(xié)議(ROHC)來(lái)進(jìn)行報(bào)頭壓縮，并且同時(shí)支持IPv4和IPv6。
典型的，對(duì)于一個(gè)含有32 Byte有效載荷的VoIP分組傳輸來(lái)說(shuō)，IPv6報(bào)頭增加60Byte，IPv4報(bào)頭增加40 Byte，即188%和125%的開銷。為了解決這個(gè)問(wèn)題，在LTE系統(tǒng)中PDCP子層采用ROHC報(bào)頭壓縮技術(shù)，可壓縮成4～6個(gè)字節(jié)，即12.5%～18.8%的相對(duì)開銷，從而提高了信道的效率和分組數(shù)據(jù)的有效性。



2.3.5SPS半持續(xù)調(diào)度


Semi-PersistentScheduling，簡(jiǎn)稱SPS，半永久性調(diào)度，又稱為半靜態(tài)調(diào)度，LTE引入SPS調(diào)度模式的主要目的是為了支持VOIP業(yè)務(wù)。SPS調(diào)度方式可以減少控制信道的資源開銷和時(shí)延抖動(dòng)，但會(huì)增加PDSCH的開銷；VOIP業(yè)務(wù)用戶語(yǔ)音包發(fā)送頻率較大，SPS周期調(diào)度時(shí)不需要每次都發(fā)送PDCCH，減少了控制區(qū)CCE的占用量，理論上可以提高系統(tǒng)用戶容量。
從語(yǔ)音業(yè)務(wù)模型上看可以知道SPS適用于語(yǔ)音業(yè)務(wù)，VoIP業(yè)務(wù)的狀態(tài)分為激活期和靜默期,在激活期，數(shù)據(jù)包的發(fā)包間隔為20ms，每個(gè)數(shù)據(jù)包的大小固定為35~47Byte。對(duì)于暫態(tài)時(shí)的數(shù)據(jù)包大小由于沒(méi)有壓縮，數(shù)據(jù)包大小為92Byte, 在靜默期，SID包的發(fā)包間隔為160ms，每個(gè)SID包的大小固定為10~22Byte，這樣規(guī)律的發(fā)送方式適用SPS調(diào)度。
總的來(lái)說(shuō)，SPS就相當(dāng)于給用戶分配了固定的PDSCH，可以減少PDCCH占用數(shù)，但會(huì)增加PDSCH占用數(shù)，是否開啟需對(duì)兩者進(jìn)行權(quán)衡。對(duì)于SPS的詳細(xì)內(nèi)容，可以參考《SPS調(diào)度-李翔》。



2.3.6eSRVCC(Enhanced Single Radio Voice Call Continuity)
SRVCC（Single Radio Voice Call Continuity）是3GPP提出的一種VoLTE語(yǔ)音業(yè)務(wù)連續(xù)性方案，主要是為了解決當(dāng)單射頻UE 在LTE/Pre-LTE 網(wǎng)絡(luò)和2G/3G CS 網(wǎng)絡(luò)之間移動(dòng)時(shí)，如何保證語(yǔ)音呼叫連續(xù)性的問(wèn)題，即保證單射頻UE 在IMS 控制的VoIP 語(yǔ)音和CS 域語(yǔ)音之間的平滑切換，SRVCC類似于UTRAN中的3G至2G的切換，主要是在CN側(cè)多了PS域到CS域的轉(zhuǎn)換過(guò)程。當(dāng)LTE覆蓋較差時(shí)，UE通過(guò)SRVCC切換到UTRAN/GERAN，目前移動(dòng)公司的方案是切換到GERAN，3GPP TS 23.216中定義E-UTRAN切換到UTRAN/GERAN的流程圖及主要信令流程如下：




eSRVCC即為增強(qiáng)的SRVCC，與SRVCC一樣為3GPP在R8階段引入的方案，相比SRVCC最大的改進(jìn)就是縮短了切換時(shí)延，改善用戶感知。SRVCC與eSRVCC的主要區(qū)別如下：
1.
SRVCC：媒體的切換點(diǎn)是對(duì)端網(wǎng)絡(luò)設(shè)備（如對(duì)端UE），影響切換時(shí)長(zhǎng)的主要因素是會(huì)話切換后需要在IMS網(wǎng)絡(luò)中創(chuàng)建新的承載。
2.
eSRVCC：相比于SRVCC，媒體切換點(diǎn)改為更靠近本端的設(shè)備。具體方案就是增加ATCF/ATGW功能實(shí)體作為媒體錨定點(diǎn)，無(wú)論是切換前還是切換后的會(huì)話消息都要經(jīng)過(guò)ATCF（Access Transfer Control Function）/ATGW（AccessTransfer Gateway）轉(zhuǎn)發(fā)。后續(xù)在發(fā)生eSRVCC切換時(shí)，只需要?jiǎng)?chuàng)建UE與ATGW之間的承載通道，對(duì)端設(shè)備與ATGW之間的媒體流還是通過(guò)原承載通道傳輸。這樣相當(dāng)于減少了SBC至SCC AS之間的時(shí)延，明顯短于SRVCC方案，減少了切換時(shí)長(zhǎng)。

3
VOLTE KPI分類及定義
VOLTE測(cè)試類指標(biāo)主要有三大類指標(biāo)，詳見下表，部分指標(biāo)為VOLTE新增指標(biāo)，指標(biāo)具體定義可以參考下面附件：

指標(biāo)分類	指標(biāo)名稱
資源占用類	上行RB數(shù)
	下行RB數(shù)
	上行MCS
	下行MCS
	上行終端發(fā)射功率
	GSM通話時(shí)長(zhǎng)占比
	呼叫SRVCC切換占比
語(yǔ)音質(zhì)量類	MoS
	BLER
	語(yǔ)音丟包率
	抖動(dòng)
	呼叫建立時(shí)延
	IP包時(shí)延
	端到端時(shí)延
	上行速率
	下行速率
	切換中斷時(shí)延
	話音掛機(jī)時(shí)延
KPI指標(biāo)類	IMS附著成功率
	話音接通成功率
	掉話率
	網(wǎng)內(nèi)切換成功率
	SRVCC切換成功率
	尋呼成功率
	平均長(zhǎng)保時(shí)間
	緊急呼叫建立成功率
	里程掉話比

VOLTE網(wǎng)管KPI指標(biāo)類主要如下表：

指標(biāo)項(xiàng)	單位	說(shuō)明
ERAB建立和RRC建立
LTE_ERAB.ErabEstabSuccRate.Qci1	%	LTE_會(huì)話類語(yǔ)音業(yè)務(wù)ERAB建立成功率_Qci1
LTE_ERAB.ErabEstabSuccRate.Qci2	%	LTE_會(huì)話類直播視頻流業(yè)務(wù)ERAB建立成功率_Qci2
LTE_ERAB.ErabEstabSuccRate.Qci5	%	LTE_IMS信令業(yè)務(wù)ERAB建立成功率_Qci5
LTE_RRC.VoLteRadioConnSuccRate	%	VoLTE無(wú)線接通率(QCI=1)
LTE_RRC.ConvVideoCallSuccRate	%	LTE_會(huì)話類直播視頻流業(yè)務(wù)無(wú)線接通率_Qci2
LTE_RRC.ImsSigCallSuccRate	%	LTE_IMS信令業(yè)務(wù)無(wú)線接通率_Qci5
掉線
ERAB掉線率QCI五	%	目前OMC預(yù)定義指標(biāo)沒(méi)有
ERAB掉線率QCI一	%	目前OMC預(yù)定義指標(biāo)沒(méi)有
ERAB掉線率QCI九	%	目前OMC預(yù)定義指標(biāo)沒(méi)有
ERAB掉線率QCI二	%	目前OMC預(yù)定義指標(biāo)沒(méi)有
LTE_ERAB.ImsSigCallDropRatio	%	LTE_IMS信令業(yè)務(wù)無(wú)線掉線率_Qci5
LTE_ERAB.ImsSigCallDropRate	%	LTE_IMS信令業(yè)務(wù)無(wú)線掉線率_Qci5_小區(qū)級(jí)
LTE_ERAB.OthersCallDropRate	%	LTE_其他類業(yè)務(wù)無(wú)線掉線率_Qci9_小區(qū)級(jí)
LTE_ERAB.OthersCallDropRatio	%	LTE_其他類業(yè)務(wù)無(wú)線掉線率_Qci9
LTE_ERAB.ConvVoiceCallDropRatio	%	LTE_會(huì)話類語(yǔ)音業(yè)務(wù)無(wú)線掉話率_Qci1
LTE_ERAB.ConvVideoCallDropRate	%	LTE_會(huì)話類直播視頻流業(yè)務(wù)無(wú)線掉話率_Qci2_小區(qū)級(jí)
LTE_ERAB.ConvVoiceCallDropRate	%	LTE_會(huì)話類語(yǔ)音業(yè)務(wù)無(wú)線掉話率_Qci1_小區(qū)級(jí)
LTE_ERAB.ConvVideoCallDropRatio	%	LTE_會(huì)話類直播視頻流業(yè)務(wù)無(wú)線掉話率_Qci2
上下行時(shí)延
LTE_PDCP.UpPktDelayDl.Qci1	毫秒	分QCI的小區(qū)用戶面下行平均時(shí)延-QCI1
LTE_PDCP.UpPktDelayDl.Qci5	毫秒	分QCI的小區(qū)用戶面下行平均時(shí)延-QCI5
LTE_PDCP.UpPktDelayDl.Qci2	毫秒	分QCI的小區(qū)用戶面下行平均時(shí)延-QCI2
LTE_PDCP.UpPktDelayDl.Qci9	毫秒	分QCI的小區(qū)用戶面下行平均時(shí)延-QCI9
LTE_PDCP.VoLteUpPktDiscardRateDl	百萬(wàn)分之一	VoLTE下行棄包率
LTE_PDCP.VoLteUpPktLossRateDl	百萬(wàn)分之一	VoLTE下行丟包率
LTE_PDCP.VoLteUpPktLossRateUl	百萬(wàn)分之一	VoLTE上行丟包率

4
VOLTE信令流程

VOLTE是基于SIP協(xié)議的語(yǔ)音通話，所有與IMS交互的信令全部為SIP信令，在理解VOLTE信令方面必須對(duì)SIP信令進(jìn)行了解，EPC只是做為業(yè)務(wù)承載體。由于SIP信令是以加密方式傳輸，SIP信令只有在CN側(cè)和終端側(cè)才能解碼，基站CDL無(wú)法記錄SIP信令，同時(shí)CDL無(wú)法解碼較多NAS層直傳消息，所以本文中的信令說(shuō)明部分不結(jié)合CDL信令進(jìn)行說(shuō)明；對(duì)于某些重要信令的詳細(xì)解碼，本文以附件方式顯示，主要為CDS導(dǎo)出的詳細(xì)解碼并對(duì)重要IE進(jìn)行標(biāo)注解釋，建議參考。


4.1注冊(cè)流程及重要信令詳解

SIP提供了發(fā)現(xiàn)機(jī)制，如果用戶要發(fā)起和另一個(gè)用戶的會(huì)話，SIP必須發(fā)現(xiàn)可到達(dá)目的用戶的當(dāng)前主機(jī)，注冊(cè)將記錄地址 URI 和一個(gè)或者多個(gè)聯(lián)系地址相關(guān)聯(lián)，這樣才能進(jìn)行呼叫等業(yè)務(wù)。
嚴(yán)格意義上說(shuō)，SUBSCRIBE和NOTIFY過(guò)程不屬于注冊(cè)過(guò)程，但由于該過(guò)程在注冊(cè)完成后緊跟著出現(xiàn)，所以本文將該過(guò)程放在注冊(cè)流程中進(jìn)行說(shuō)明。用戶的注銷過(guò)程與注冊(cè)過(guò)程相似，主要就是注銷請(qǐng)求中,expire值為0，所以本文中不再進(jìn)行單獨(dú)說(shuō)明，注銷過(guò)程無(wú)SUBSCRIBE信令，是因?yàn)閁E注冊(cè)時(shí)已有SUBSCRIBE。

信令說(shuō)明如下：
1、
UE進(jìn)行Attach，建立QCI=9的默認(rèn)承載，并使用IMS APN建立PDN連接；
2、
建立立QCI=5的默認(rèn)承載，用于傳送SIP信令；
3、
UE通過(guò)QCI=5的默認(rèn)承載向IMS發(fā)起注冊(cè)請(qǐng)求；
4、
P-CSCF通過(guò)HSS獲知用戶信息不在數(shù)據(jù)庫(kù)中，便向終端代理回送401 Unauthorized
質(zhì)詢信息，其中包含安全認(rèn)證所需的令牌；
5、
終端將用戶標(biāo)識(shí)和密碼根據(jù)安全認(rèn)證令牌加密后，再次用REGISTER消息報(bào)告給P-CSCF服務(wù)器；
6、
P-CSCF將REGISTER 消息中的用戶信息解密，驗(yàn)證其合法后，IMS核心網(wǎng)將該用戶信息登記到數(shù)據(jù)庫(kù)中，并向終端返回成功響應(yīng)消息200 OK；
7、
用戶向IMS訂閱注冊(cè)事件包
8、
服務(wù)器應(yīng)答訂閱成功
9、
IMS服務(wù)器發(fā)送notify消息，由于訂閱的用戶已經(jīng)注冊(cè)，所以IMS服務(wù)器回應(yīng)Notify消息中，狀態(tài)為active，同時(shí)攜帶XML信息
10、
終端發(fā)送Notify 200表示接收成功
注冊(cè)過(guò)程測(cè)試信令載圖如下：

注銷過(guò)程測(cè)試信令截圖如下：

4.1.1Activate Default EPS Bearer Context Request（QCI=5）

該信令是用于建立QCI=5的默認(rèn)承載，所有SIP信令都通過(guò)QCI=5的承載傳輸，該信令的內(nèi)容已在該信令前的RRC重配置中附帶下來(lái)。
CDS導(dǎo)出的詳細(xì)解碼如下：



主要說(shuō)明如下：
該信令中主要是關(guān)注QCI等級(jí)，必須是QCI=5，才能傳輸SIP信令，ERABID=6

4.1.2REGISTER(1ST Sip Register Request)&REGISTER 401（Unauthorized）
REGISTER信令是用于網(wǎng)絡(luò)注冊(cè)，建立關(guān)聯(lián)
從CDS上導(dǎo)出的詳細(xì)解碼如下：

主要說(shuō)明如下：
這是用戶的第一個(gè)REGISTER REQUST信令，所以鑒權(quán)方面部分內(nèi)容為空，需要網(wǎng)絡(luò)回應(yīng)后才能補(bǔ)齊

REGISTER 401信令是用于向終端回送401 Unauthorized 質(zhì)詢信息，其中包含安全認(rèn)證所需的令牌，令牌對(duì)應(yīng)用戶第一個(gè)REGISTER REQUST信令中鑒權(quán)摘要為空的部分，并指明算法，主要說(shuō)明如下：

4.1.3REGISTER(2nd Sip RegisterRequest)& REGISTER 200
第二條Register信令是終端將用戶標(biāo)識(shí)和密碼根據(jù)安全認(rèn)證令牌加密后回送給服務(wù)器
CDS上導(dǎo)出的詳細(xì)解碼如下：

主要說(shuō)明如下：

REGISTER 200信令是用是確認(rèn)注冊(cè)流程完成，并生成SIP-URI和TEL URI，3GPPTS 23.003定義了三種URI如下，VOLTE中使用了后面兩種：
Alphanumeric SIP-URIs
Example: sip:voicemail@example.com
MSISDN represented as a SIP URI:
Example:sip:+447700900123@example.com;user=phone
MSISDN represented as a Tel URI:
 Example: tel:+447700900123：
REGISTER 200信令截圖如下：

4.1.4SUBSCRIBE& NOTIFY
SUBSCRIBE是一個(gè)用來(lái)請(qǐng)求對(duì)方節(jié)點(diǎn)的當(dāng)前狀態(tài)以及后續(xù)狀態(tài)變化的請(qǐng)求方法,從網(wǎng)絡(luò)訂閱消息，NOTIFY是用于向服務(wù)器請(qǐng)求返回當(dāng)前狀態(tài)消息。
VOLTE中典型的消息流如下：

如果訂閱過(guò)期了，就必須發(fā)起新的SUBSCRIBE來(lái)進(jìn)行訂閱
SUBSCRIBE CDS信令截圖如下：

SUBSCRIBE 200 CDS信令截圖如下

網(wǎng)絡(luò)通過(guò)NOTIFY向UE發(fā)送訂閱的內(nèi)容，UE通過(guò)NOTIFY 200確認(rèn)已收到，NOTIFY的CDS信令截圖如下：



4.2語(yǔ)音通話流程及重要信令詳解

語(yǔ)音呼叫過(guò)程就是為典型的SIP通話過(guò)程，經(jīng)過(guò)多個(gè)修改，基本已經(jīng)定型。由于VOLTE呼叫其它通話制式的手機(jī)時(shí)，VOLTE終端側(cè)的信令未有變化，所以本文中不會(huì)進(jìn)行說(shuō)明。
CDS軟件信令截圖如下：



呼叫流程圖如下：

信令說(shuō)明如下：
1．1到6，UE起呼，UE高層協(xié)議層需要發(fā)送INVITE到IMS，觸發(fā)RRC連接、安全模式等過(guò)程，并通過(guò)RRC重配置消息建立SRB2信令無(wú)線承載、恢復(fù)QCI 5承載，配置測(cè)量控制，IMS收到主叫的INITE消息，開始尋呼，并發(fā)送INVITE 100（TRYING）給主叫UE，用于響應(yīng)INVITE消息，INVITE消息中包含呼叫類型、主被叫的號(hào)碼、主叫方支持的媒體類型和編碼等；
2．7到15，核心網(wǎng)向處于空閑態(tài)的被叫發(fā)INVITE消息，由于被叫處于空閑態(tài)，所以核心網(wǎng)側(cè)觸發(fā)尋呼消息，尋呼處于空閑態(tài)的被叫用戶，被叫UE收到尋呼后，觸發(fā)RRC連接、安全模式等過(guò)程，被叫通過(guò)RRC重配置消息建立SRB2信令無(wú)線承載，CN側(cè)通過(guò)QCI=5的RB向被叫發(fā)送INVITE消息，UE收到后發(fā)送INVITE 100消息進(jìn)行響應(yīng)，同時(shí)被叫發(fā)送INVITE 183消息給CN表示會(huì)話正在處理，啟動(dòng)Precondition(資源預(yù)留)過(guò)程，并通知主叫自己所支持的媒體類型和編碼，并建立起QCI=1的承載；
3. 16到17，IMS收到被叫的INVITE 83后，對(duì)主叫啟動(dòng)Precondition(資源預(yù)留)過(guò)程，通過(guò)EPC通知主叫SM層建立起QCI=1的承載后，向UE發(fā)送INVITE 183消息；
4．18到25，主叫向被叫發(fā)送PRACK消息，PRACK過(guò)程是一個(gè)預(yù)確認(rèn)過(guò)程，主要為了防止會(huì)話超時(shí)及擁塞，被叫收到后返回PRACK200，主叫收到被叫的PRACK 200以后，發(fā)送UPDATE消息，進(jìn)行媒體格式協(xié)商過(guò)程，被叫通過(guò)UPDATE 200返回協(xié)商結(jié)果；
5. 26到31是振鈴接聽過(guò)程，被叫發(fā)送INVITE 180給主叫，振鈴，摘機(jī)后發(fā)送INVITE 200給主叫，主叫返回ACK進(jìn)行確認(rèn)，通話完全建立，進(jìn)入通話過(guò)程；
6. 32到37為掛機(jī)過(guò)程 ，通話結(jié)束后，主叫發(fā)送BYE請(qǐng)求結(jié)束本次會(huì)話，IMS服務(wù)器給被叫發(fā)送BYE,請(qǐng)求結(jié)束本次會(huì)話，被叫掛機(jī)，回BYE 200消息，核心網(wǎng)IMS服務(wù)器給主叫發(fā)BYE 200，標(biāo)明會(huì)話結(jié)束，主被叫分別去激活EPS專用承載消息，刪除QCI=1的數(shù)據(jù)無(wú)線承載。


4.2.1INVITE
INVITE是發(fā)起會(huì)話邀請(qǐng)，在VOLTE中就是用于起呼，INVITE消息中主要包含了主叫信息、被叫號(hào)碼和主叫支持的格式
信令截圖如下：

4.2.2RRCConnectionReconfiguration （QCI=1）
該信令對(duì)應(yīng)流程中的步驟13、14的RRCConnectionReconfiguration，在核心網(wǎng)下發(fā)“Activate Dedicated EPS Bearer Context Request”消息后，基站將該消息附加在“RRCConnectionReconfiguration”消息中一起下發(fā)，所以“RRCConnectionReconfiguration”中解碼出來(lái)的“ActivateDedicated EPS Bearer Context Request”消息內(nèi)容，與后續(xù)的“ActivateDedicated EPS Bearer Context Request”消息內(nèi)容一致，RRCConnectionReconfiguration在CDS上導(dǎo)出的詳細(xì)解碼如下：

主要說(shuō)明如下：
1.
在pdcp-ConfigàheaderCompression可以查到頭壓縮的的相關(guān)配置，主要內(nèi)容為頭壓縮使用的方案格式；
2.
在mac-MainConfig節(jié)點(diǎn)下可以查到ttiBundling功能是否開啟；

3.
在該消息中如果查不到關(guān)于SPS的IE，則說(shuō)明SPS為關(guān)閉狀態(tài)；
如果SPS開啟，SPS在信令中的格式如下：

4.2.3UPDATE & UPDATE 200
UPDATE主要是用于在呼叫過(guò)程中進(jìn)行媒體格式的二次協(xié)商，UPDATE 200消息是對(duì)UPDATE消息的確認(rèn)，UPDATE 200消息中協(xié)商結(jié)果為雙方通話使用的通話格式，通常選取主被叫雙方中格式中較低的一種，主被叫雙方根據(jù)協(xié)商結(jié)果，通過(guò)“Modify EPS Bearer Context Request”消息對(duì)EPS承載進(jìn)行相應(yīng)的修改。
在UPDATE消息中攜帶了主要建議的語(yǔ)音編碼格式，好點(diǎn)正常語(yǔ)音業(yè)務(wù)上下行各占用2個(gè)PRB左右，標(biāo)清語(yǔ)音和高清語(yǔ)音資源占用基本相同，但差點(diǎn)標(biāo)清PRB占用數(shù)會(huì)少一些，未來(lái)移動(dòng)也有可能推廣標(biāo)清語(yǔ)音。

在收到的UPDATE 200消息中的編碼格式為最終格式，截圖如下：
如果呼叫2/3G、固話等，協(xié)商結(jié)果為2/3G、固定電話的編碼為準(zhǔn)，例如下圖中為呼叫2G的UPDATE 200消息，協(xié)商結(jié)果使用AMR-NB的編碼格式

4.2.4視頻通話流程與語(yǔ)音通話流程的異同
視頻電話與語(yǔ)音通話過(guò)程基本相同，其中最主要的區(qū)別是需要建立QCI=1和QCI=2的承載，QCI=1傳送語(yǔ)音，QCI=2傳送視頻，視頻電話的信令截圖如下,其中需要注意的是正常結(jié)束后會(huì)去激活兩個(gè)承載。



主要區(qū)別如下：
1、語(yǔ)音業(yè)務(wù)INVITE消息中，呼叫的原因?yàn)檎Z(yǔ)音，只攜帶支持的語(yǔ)音編碼格式，視頻業(yè)務(wù)的INVITE中呼叫原因?yàn)橐曨l，并攜帶了主叫支持的視頻編碼格式。

2、
視頻業(yè)務(wù)需要建立兩條業(yè)務(wù)承載，QCI=1和QCI=2,這與3G的視頻電視只建議一個(gè)承載不同，同時(shí)視頻業(yè)務(wù)釋放時(shí)需要釋放兩條承載；





4.3eSRVCC切換及重要信令詳解
VOLTE系統(tǒng)內(nèi)切換與R8/9的切換相同，所以本文只針對(duì)eSRVCC切換流程進(jìn)行說(shuō)明；SRVCC切換流程在3GPP協(xié)議TS 23.216里定義，有多種SRVCC流程，本文介紹的是“SRVCC from E-UTRAN to GERANwithout DTM support ”流程。eSRVCC切換過(guò)程比較簡(jiǎn)單，與TD-SCDMA中的CS系統(tǒng)間切換流程相似，通過(guò)對(duì)比可以加深理解。eSRVCC的主要流程為A2àB2àHOàRELEASE，目前移動(dòng)公司的策略是從LTE切向GERAN，本文只說(shuō)明LTE向GERAN的SRVCC切換過(guò)程。
測(cè)試軟件UU口信令截圖如下：

CDL解碼截圖如下：

信令流程如下：

信令說(shuō)明只說(shuō)明UU口和S1口的信令，其它步驟詳細(xì)說(shuō)明見本節(jié)最后面的附件或查詢 TS 23.216的6.2.2.1，主要說(shuō)明如下：
1、
步驟1 UE上報(bào)B2報(bào)告，基站會(huì)發(fā)起切換判決，這里有兩個(gè)注意事項(xiàng)，必須UE和CN側(cè)均支持SRVCC切換，基站RRM才會(huì)有步驟2判決進(jìn)行SRVCC切換，否則判決為重定向，詳見本文4.3.1；
2、

步驟3 eNodeB向源MME發(fā)送Handover Required消息，該消息中包含括Target ID（多為CGI）、generic Source to Target TransparentContainer、 SRVCC切換指示等。SRVCC HO 指標(biāo)標(biāo)明切換目標(biāo)只是CS域；
3、
步驟 14和15，MME和目標(biāo)MSC、IMS等經(jīng)過(guò)一系統(tǒng)交互過(guò)程后，完成PS到CS的轉(zhuǎn)換過(guò)程及目標(biāo)小區(qū)資源預(yù)留后，MME向eNodeB發(fā)送 HandoverCommand， eNodeB通過(guò)MobilityFromEUTRACommand通知UE進(jìn)行切換。
4、
步驟16到18，UE切換到GSM,進(jìn)行同步過(guò)程，同步后UE發(fā)現(xiàn)Suspend過(guò)程，對(duì)GPRS業(yè)務(wù)掛起，后續(xù)CN側(cè)會(huì)數(shù)據(jù)業(yè)務(wù)掛起及通知MME進(jìn)行鏈路釋放等一系列過(guò)程，切換完成。
如果在CS 語(yǔ)音結(jié)束后UE還在GERAN(or for any other reason specifiedin TS 24.008), UE則需要按照TS 23.060規(guī)定恢復(fù)PS業(yè)務(wù). GN SGSN將按照TS23.060 規(guī)定恢復(fù)PDP上下文， S4 SGSN將按照TS 23.060 規(guī)定恢復(fù)承載，并且通知S- GW和P-GW(s)恢復(fù)暫停的承載；如果UE在CS語(yǔ)音呼叫終止后已經(jīng)返回到E-UTRAN，則UE必須通過(guò)發(fā)送TAU向MME恢復(fù)PS服務(wù)， MME將通知S-GW and P-GW(s)恢復(fù)掛起的承載，恢復(fù)在S-GW和P-GW中掛起的承載，應(yīng)該通過(guò)使用某種操作觸發(fā)Modify Bearer request消息進(jìn)行隱式恢復(fù)，例如RAU、TAU 或ServiceRequest。S- GW知道承載的暫停狀態(tài)，并且將轉(zhuǎn)發(fā)ModifyBearer request消息到P- GW，如果ModifyBearer Request不是由某類操作觸發(fā)時(shí)，直接恢復(fù)必須使用恢復(fù)指示消息。

4.3.1Attach Request& Initial ContextSetup Request
Attach Request信令與Attach過(guò)程中的 InitialContext Setup Request信令分別包含了UE和網(wǎng)絡(luò)的SRVCC能力，這是進(jìn)行SRVCC的必要條件。

下面從CDS上導(dǎo)出的Attach Request信令詳細(xì)解碼

主要說(shuō)明如下：
從Attach Request信令中可以得到UE對(duì)SRVCC的能力，消息中其它內(nèi)容與平常的信令相同，UE將 SRVCC capability indication作為“UE Network Capability”的一部分包含在Attach Requestmessage/Tacking Area updaterequest中發(fā)送給MME

Initial Context Setup Request：注意該消息必須是在Attach過(guò)程中的消息才攜帶SRVCC能力部分。

注意事項(xiàng)：
1、SRVCC與SIM卡簽約業(yè)務(wù)有關(guān)，HSS向MME指示UE的簽約信息（STN-SR）是否支持SRVCC


5
常見問(wèn)題案例
6.1SIM卡無(wú)VoLTE權(quán)限導(dǎo)致注冊(cè)失敗
【問(wèn)題現(xiàn)象】

浙江麗水項(xiàng)目在市移動(dòng)公司申請(qǐng)4張，均IMS注冊(cè)失敗，導(dǎo)致無(wú)法進(jìn)行VOLTE業(yè)務(wù)測(cè)試。

【問(wèn)題分析】
1、
UE ATTACH過(guò)程正常，已建立QCI 9的默認(rèn)承載，如下圖所示，APN為CMNE

2、UE發(fā)起APN為IMS的PDN連接請(qǐng)求后，MME下發(fā)第二個(gè)默認(rèn)承載的建立請(qǐng)求，正常情況下建立QCI 5的默認(rèn)承載，而MME實(shí)際下發(fā)的是QCI 9的承載建立，且APN仍為CMNET的APN，導(dǎo)致建立失敗，從而導(dǎo)致無(wú)法進(jìn)行IMS注冊(cè)過(guò)程，下圖中左邊為正常PDN連接請(qǐng)求后下發(fā)QCI 5默認(rèn)承載建立的信令解碼，右邊部分為異常解碼。

懷疑可能有以下兩個(gè)原因?qū)е拢?/font>
1、
SIM 卡無(wú)VOLTE權(quán)限；
2、
PGW的P-CSCF發(fā)現(xiàn)功能部份設(shè)置錯(cuò)誤
【問(wèn)題解決】

經(jīng)市公司核查后得知，地市公司無(wú)權(quán)限開通VOLTE測(cè)試卡，導(dǎo)致所開通的SIM無(wú)法注冊(cè)，已向省公司重新申請(qǐng)SIM卡。


6.2 SIM授權(quán)問(wèn)題導(dǎo)致eSRVCC無(wú)法執(zhí)行【問(wèn)題現(xiàn)象】
在VOLTE測(cè)試過(guò)程中發(fā)現(xiàn)在RSRP變差到-110以后不能切換到2G而是重定向到2G，這樣不符合規(guī)范，MOS值會(huì)中斷，再次呼叫會(huì)引起未接通，從下圖復(fù)測(cè)過(guò)程中可以看到上報(bào)B2以后不是正常的發(fā)起eSRVCC切換流程而是直接Release（重定向）。

【問(wèn)題分析】
在該區(qū)域多次進(jìn)行測(cè)試發(fā)現(xiàn)依舊如此，更換終端以后進(jìn)行測(cè)試還是會(huì)重定向到2G，懷疑是否是基站參數(shù)問(wèn)題，對(duì)基站參數(shù)進(jìn)行檢查并沒(méi)有發(fā)現(xiàn)異常設(shè)置,對(duì)比能正常切換的流程，少了RRM判決系統(tǒng)間切換的過(guò)程，基站版本是6.10.24，是否是基站RRM判決異常還是參數(shù)原因


更換SIM進(jìn)行驗(yàn)證以后發(fā)現(xiàn)可以正常的進(jìn)行eSRVCC切換，懷疑是SIM授權(quán)出現(xiàn)問(wèn)題，對(duì)比信令流程發(fā)現(xiàn)在上下文建立請(qǐng)求中核心網(wǎng)沒(méi)有帶SRVCC能力，而正常的流程中攜帶有SRVCC能力如下圖：
不攜帶SRVCC能力：

攜帶SRVCC能力：

【問(wèn)題解決】
大規(guī)模上VOLTE部署以后如果遇到此類問(wèn)題建議首先確認(rèn)SIM卡的授權(quán)SRVCC功能是否正常。


6.3廣東云浮項(xiàng)目呼叫建立時(shí)延過(guò)長(zhǎng)【問(wèn)題現(xiàn)象】

廣東云浮項(xiàng)目VOLTE測(cè)試，呼叫建立時(shí)延可長(zhǎng)達(dá)5-8S，比2、3G建立時(shí)延還長(zhǎng)

【問(wèn)題分析】
1、主叫發(fā)了INVITE后，到IMS開始尋呼用了0.4S，但是被叫在4秒后才收到尋呼，懷疑HSS在查找被叫號(hào)碼時(shí)時(shí)間過(guò)久

2、主叫先于被叫建立QCI1專載，和規(guī)范流程不合，正常只有IMS處理有問(wèn)題才會(huì)這樣

【問(wèn)題解決】
將問(wèn)題反映給地市移動(dòng)公司，要求協(xié)調(diào)核查HSS與IMS是否部署完畢，移動(dòng)最后反饋，云浮暫時(shí)掛靠在深圳的測(cè)試IMS上，HSS為廣州HSS，均在調(diào)試階段，未正式投入使用，性能還不能達(dá)到正常使用程度，需調(diào)試完成后才能解決。