VoLTE原理簡介

項目名稱
文檔編號
版 本 號
部 門	專業(yè)服務部
作 者

版權所有
大唐移動通信設備有限公司


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

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

目錄
[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預期讀者和閱讀建議... 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技術背景... 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技術優(yōu)勢... 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)架構... 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關鍵技術... 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無線承載Qos等級標識
（譯成中文，李）... 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語音編碼... 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健壯性報頭壓縮協(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ù)調度... 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注冊流程及重要信令詳解... 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語音通話流程及重要信令詳解... 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視頻通話流程與語音通話流程的異同... 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
常見問題案例... 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卡無VoLTE權限導致注冊失敗... 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授權問題導致eSRVCC無法執(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廣東云浮項目呼叫建立時延過長... 39[/url]



1
引言
1.1 編寫目的

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

1.2預期讀者和閱讀建議

本文檔預期讀者為網絡技術優(yōu)化人員、系統(tǒng)測試人員等。

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

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

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

中移動二階段VOLTE福州測試的網絡拓樸如下：
VOLTE的協(xié)議架構如下圖，從圖中可以看到，SIP協(xié)議只在終端和IMS支持，對于無線接入網只是一個透傳做用：

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

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

2.3.2AMR-WB語音編碼
AMR全稱AdaptiveMulti-Rate，自適應多速率編碼，主要用于移動設備的音頻，壓縮比比較大，但相對其他的壓縮格式質量比較差，但主要用于人聲，所以效果較好。2/3使用的語音編碼格式為AMR-NB，語音帶寬范圍：300－3400Hz，8KHz采樣率，VoLTE使用AMR-WB編碼，提供語音帶寬范圍達到50～7000Hz，16KHz采樣率用戶可主觀感受到話音比以前更加自然、舒適和易于分辨。
AMR 一共有16種編碼方式， 0-7對應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種語音編碼，目前主要使用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)網行業(yè)標準組織IETF提出的，SIP(Session Initiation Protocol)是一個應用層的信令控制協(xié)議。用于創(chuàng)建、修改和釋放一個或多個參與者的會話。這些會話可以是Internet多媒體會議、IP電話或多媒體分發(fā)。會話的參與者可以通過組播（multicast）、網狀單播（unicast）或兩者的混合體進行通信。VoLTE選擇了SIP協(xié)議，最主要的原因就是免費。

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

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

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

· 臨時響應（1XX）：臨時響應被服務器用來指示進程，但是不終結SIP事物。

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

1xx	進展相應	臨時相應
2xx	成功	最終相應
3xx	重定向錯誤	最終相應
4xx	客戶端錯誤	最終相應
5xx	服務端錯誤	最終相應
6xx	全局錯誤	最終相應

SIP由于是采用文本格式編碼，所以消息格式很簡單，是由Message Header加可選的Message body構成，Message Header 從第二行開始每一行都由“Tag :Valued”格式組成，每一行描述一個屬性，SDP也是用文本格式描述的，一個SDP Description可以包含很多行，每一行的格式如下：
Type = Value
Type只用一個字母來表示；一個SDP Description通常有一個Session-level和多個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健壯性報頭壓縮協(xié)議
在LTE中，為了在分組交換域(PS)提供語音業(yè)務且到達接近常規(guī)電路交換域的效率，必須對IP/UDP/RTP報頭進行壓縮。對于話音數(shù)據包，其包長較小，封裝成IP包后，采用頭壓縮技術能有效提高頻譜利用率，對于視頻業(yè)務數(shù)據包，同樣壓縮后也可以提高頻譜效率。在LTE系統(tǒng)中，規(guī)定PDCP子層支持健壯性報頭壓縮協(xié)議(ROHC)來進行報頭壓縮，并且同時支持IPv4和IPv6。
典型的，對于一個含有32 Byte有效載荷的VoIP分組傳輸來說，IPv6報頭增加60Byte，IPv4報頭增加40 Byte，即188%和125%的開銷。為了解決這個問題，在LTE系統(tǒng)中PDCP子層采用ROHC報頭壓縮技術，可壓縮成4～6個字節(jié)，即12.5%～18.8%的相對開銷，從而提高了信道的效率和分組數(shù)據的有效性。



2.3.5SPS半持續(xù)調度


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



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




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

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

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

VOLTE網管KPI指標類主要如下表：

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

4
VOLTE信令流程

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


4.1注冊流程及重要信令詳解

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

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

注銷過程測試信令截圖如下：

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

該信令是用于建立QCI=5的默認承載，所有SIP信令都通過QCI=5的承載傳輸，該信令的內容已在該信令前的RRC重配置中附帶下來。
CDS導出的詳細解碼如下：



主要說明如下：
該信令中主要是關注QCI等級，必須是QCI=5，才能傳輸SIP信令，ERABID=6

4.1.2REGISTER(1ST Sip Register Request)&REGISTER 401（Unauthorized）
REGISTER信令是用于網絡注冊，建立關聯(lián)
從CDS上導出的詳細解碼如下：

主要說明如下：
這是用戶的第一個REGISTER REQUST信令，所以鑒權方面部分內容為空，需要網絡回應后才能補齊

REGISTER 401信令是用于向終端回送401 Unauthorized 質詢信息，其中包含安全認證所需的令牌，令牌對應用戶第一個REGISTER REQUST信令中鑒權摘要為空的部分，并指明算法，主要說明如下：

4.1.3REGISTER(2nd Sip RegisterRequest)& REGISTER 200
第二條Register信令是終端將用戶標識和密碼根據安全認證令牌加密后回送給服務器
CDS上導出的詳細解碼如下：

主要說明如下：

REGISTER 200信令是用是確認注冊流程完成，并生成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是一個用來請求對方節(jié)點的當前狀態(tài)以及后續(xù)狀態(tài)變化的請求方法,從網絡訂閱消息，NOTIFY是用于向服務器請求返回當前狀態(tài)消息。
VOLTE中典型的消息流如下：

如果訂閱過期了，就必須發(fā)起新的SUBSCRIBE來進行訂閱
SUBSCRIBE CDS信令截圖如下：

SUBSCRIBE 200 CDS信令截圖如下

網絡通過NOTIFY向UE發(fā)送訂閱的內容，UE通過NOTIFY 200確認已收到，NOTIFY的CDS信令截圖如下：



4.2語音通話流程及重要信令詳解

語音呼叫過程就是為典型的SIP通話過程，經過多個修改，基本已經定型。由于VOLTE呼叫其它通話制式的手機時，VOLTE終端側的信令未有變化，所以本文中不會進行說明。
CDS軟件信令截圖如下：



呼叫流程圖如下：

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


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

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

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

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

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

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

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



主要區(qū)別如下：
1、語音業(yè)務INVITE消息中，呼叫的原因為語音，只攜帶支持的語音編碼格式，視頻業(yè)務的INVITE中呼叫原因為視頻，并攜帶了主叫支持的視頻編碼格式。

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





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

CDL解碼截圖如下：

信令流程如下：

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

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

4.3.1Attach Request& Initial ContextSetup Request
Attach Request信令與Attach過程中的 InitialContext Setup Request信令分別包含了UE和網絡的SRVCC能力，這是進行SRVCC的必要條件。

下面從CDS上導出的Attach Request信令詳細解碼

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

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

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


5
常見問題案例
6.1SIM卡無VoLTE權限導致注冊失敗
【問題現(xiàn)象】

浙江麗水項目在市移動公司申請4張，均IMS注冊失敗，導致無法進行VOLTE業(yè)務測試。

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

2、UE發(fā)起APN為IMS的PDN連接請求后，MME下發(fā)第二個默認承載的建立請求，正常情況下建立QCI 5的默認承載，而MME實際下發(fā)的是QCI 9的承載建立，且APN仍為CMNET的APN，導致建立失敗，從而導致無法進行IMS注冊過程，下圖中左邊為正常PDN連接請求后下發(fā)QCI 5默認承載建立的信令解碼，右邊部分為異常解碼。

懷疑可能有以下兩個原因導致：
1、
SIM 卡無VOLTE權限；
2、
PGW的P-CSCF發(fā)現(xiàn)功能部份設置錯誤
【問題解決】

經市公司核查后得知，地市公司無權限開通VOLTE測試卡，導致所開通的SIM無法注冊，已向省公司重新申請SIM卡。


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

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


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

攜帶SRVCC能力：

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


6.3廣東云浮項目呼叫建立時延過長【問題現(xiàn)象】

廣東云浮項目VOLTE測試，呼叫建立時延可長達5-8S，比2、3G建立時延還長

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

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

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