VOLTE技术原理与信令流程



VOLTE原理报告

项目名称	中移动福州VOLTE测试
文档编号
版 本 号	1.0.1
作    者	苏晓群

版权所有

大唐移动通信设备有限公司

本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。

文档更新记录

日期	更新人	版本	备注
2014-11-19	苏晓群	1.0.0	创建文档
2014-12-14	苏晓群	1.0.1	呼叫信令流程更新为改进后的流程

1引言

1.1 编写目的

本文主要对VOLTE的原理进行介绍，并对VOLTE小区主要参数配置及测试信令进行详细说明，使读者对VOLTE有个基本的了解；由于VOLTE现在未商用，所以实际优化经验较少，优化可以参考R9及2/3G的优化经验。

1.2预期读者和阅读建议

本文档预期读者为网络技术优化人员、系统测试人员等。

1.3参考资料

[1] 《TD-LTE半持续调度特性实现报告》

[2] 3GPP TS 23.216 Single Radio Voice Call Continuity (SRVCC)

[3]  IETF RFC 3261 Session Initiation Protocol

[4]  IR.92 -IMS Profile for Voice and SMS

[5]《中国移动VoLTE总体建设方案》—移动集团设计院 

2VOLTE原理介绍

2.1   VOLTE介绍

2.1.1  技术背景

目前业界对LTE语音的解决方案有三种，分别是VOLTE、CSFB、SGLTE， VOLTE与CSFB是3GPP标准化方案，SGLTE为终端实现方案，其中VOLTE是移动4G语音解决方案的终极方案；SGLTE不需要对网络进行改动，VOLTE与CSFB均需对网络进行改造。

VOLTE是什么？最直接简单的理解就是VOIP，只是网络的承载体由互联网变成了LTE，同时在LTE的业务中给了一个高优先级保证QOS。

VoLTE是GSMA IR 92定义的标准LTE语音解决方案，最大的网络改动就是引入IMS网络，由IMS配合LTE和EPC网络实现端到端的基于分组域的语音、视频通信业务。通过IMS系统的控制，VoLTE解决方案可以提供和电路域性能相当的语音业务及其补充业务，包括号码显示、呼叫转移、呼叫等待、会议电话等。

2.1.2  技术优势

VoLTE开启了向移动宽带语音演进之路，其给运营商带来两方面的价值，一是提升无线频谱利用率、降低网络成本。LTE的频谱利用效率GSM的4倍以上。另一个价值就是提升用户体验，VoLTE的体验明显优于传统CS语音。首先，高清语音和视频编解码的引入显著提高了通信质量；其次，VoLTE的呼叫接续时长大幅缩短，VoLTE比CS呼叫缩短一半以上。

下面是实际测试的一些指标：

呼叫建立时延更短：第一条随机接入消息到终端接收到网络侧下发的SIP 180 Ring消息之间的时间差，在外场短呼测试中看到平均时延为2S左右，而2G时代在6-7秒，用户感知为秒通。

语音质量更高：因为使用23.85K宽带AMR技术，语音质量相比2G、3G语音质量有质的提高，在外场测试时，在好点MOS值在4.1左右，而3G MOS值在3.0—3.5之间，在同一地点的OTT语音在3.5左右（无线资源不受限）。对运营商来说在这一点上体现了移动网络相对于OTT的优势。

系统间切换方面使用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*0 720P/1080P possible	分辨率：176*144
频谱效率	仿真测试结果显示：同样承载AMR，LTE的频谱效率可达到R99 3倍以上

2.2  VOLTE系统架构

VOLTE采用IMS作为业务控制层系统，EPC仅作为承载层；要求终端、无线网络、分组域、电路域和IMS域端到端的技术配合以实现基于IMS的分组域语音和多媒体业务。SRVCC切换解决了语音连续性问题，呼叫时延短，无需回落2G/3G发起语音，避免频繁网间重选。VOTLE网络框架图如下：

中移动二阶段VOLTE福州测试的网络拓朴如下：

VOLTE的协议架构如下图，从图中可以看到，SIP协议只在终端和IMS支持，对于无线接入网只是一个透传做用：

2.3  VOTLTE关键技术

2.3.1  无线承载Qos等级标识 

EPS系统中，QoS控制的基本粒度是EPS承载(Bearer)，即相同承载上的所有数据流将获得相同的QoS保障（如调度策略，缓冲队列管理，链路层配置等），不同的QoS保障需要不同类型的EPS承载来提供，在接入网中，空口上承载的QoS是由eNodeB来控制的， 每个承载都有相应的QoS参数QCI（QoS Class Identifier）。

根据QoS的不同， EPS Bear可以划分为两大类： GBR(Guranteed Bit Rate) 和 Non－GBR。所谓GBR，是指承载要求的比特速率被网络“永久”恒定的分配，即使在网络资源紧张的情况下，相应的比特速率也能够保持。MBR(Maximum Bit Rate)参数定义了GBR Bear在资源充足的条件下，能够达到的速率上限。MBR的值有可能大于或等于GBR的值。相反的，Non－GBR指的是在网络拥挤的情况下，业务（或者承载）需要承受降低速率的要求，由于Non－GBR承载不需要占用固定的网络资源，因而可以长时间地建立。而GBR承载一般只是在需要时才建立。

    LTE有9种不同的QCI，在VOLTE业务中主要用到了QCI 1、QCI 2、QCI 5，而普通的数据业务主要是QCI 8/9。不同QCI列表如下图，IMS信令使用QCI 5，语音业务共使用QCI 1、QCI 5、QCI 8/9，视频电话业务共使用QCI 1、QCI 2、QCI 5、QCI 8/9。

QCI	Resource Type	Priority	Packet Delay Budget (NOTE 1)	Packet Error Loss ate (NOTE 2)	Example Services
1(NOTE 3)	GBR	2	100 ms	10-2	Conversational Voice
2(NOTE 3)		4	150 ms	10-3	Conversational Video (Live Streaming)
3(NOTE 3)		3	50 ms	10-3	Real Time Gaming
4(NOTE 3)		5	300 ms	10-6	Non-Conversational Video (Buffered Streaming)
5(NOTE 3)	Non-GBR	1	100 ms	10-6	IMS Signalling
6(NOTE 4)		6	300 ms	10-6	Video (Buffered Streaming)     TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
7(NOTE 3)		7	100 ms	10-3	Voice,Video (Live Streaming),Interactive Gaming
8(NOTE 5)		8	300 ms	10-6	Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file
9(NOTE 6)		9			sharing, progressive video, etc.)

2.3.2  SIP(Session Initiation Protocol)&SDP

  SIP协议是互联网行业标准组织IETF提出的，SIP(Session Initiation Protocol)是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议 、IP电话或多媒体分发。会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。VOLTE选择了SIP协议，最主要的原因就是免费。

     在VOLTE中引入了IMS，对VOLTE进行业务控制，MME只是做为业务的承载体，IMS对业务的控制全部通过SIP消息完成，在学习VOLTE的过程中必须学习SIP消息。

SIP有两种类型的消息，它们是： 

（1）请求：从客户机发到服务器的消息。 

（2）响应：从服务器发到客户机的消息。 

　其中VOLTE常用的请求消息包括下列几种，表中也列出了消息的定义文档：

Request Name	Description	Defined in
INVITE	indicates a client is being invited to participate in a call session	RFC3261
ACK	Confirms that the client has received a final response to an INVITE request	RFC3261
BYE	Terminates a call and can be sent by caller or the callee	RFC3261
OPTIONS	Queries the capabilities of servers	RFC3261
CANCEL	Cancel any pending request	RFC3261
REGISTER	Registers the address listed in the To header field with SIP Server	RFC3261
PRACK	Provisional acknowledgement	RFC3262
SUBSCRIBE	Subscribes for an Event of Notification from the Notifier	RFC3265
NOTIFY	Notify the subscriber of a new Event	RFC3265
UPDATE	Modifies the state of a session without changing the state of the dialog	RFC3311
PUBLISH	Publishes an event to the Server	RFC3903
INFO	Sends mid-session information that does not modify the session state	RFC6086
REFER	Asks recipient to issue SIP request(call transfer)	RFC3515
MESSAGE	Transports instant messages using SIP	RFC3248

 响应消息包含数字响应代码，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	Bandwidth information
o	Owner of the session and session identifier
z	Time zone adjustments
s	Name of the session
k	Encryption key
i	Information about the session
a	Attribute lines
u	URL containing a description of the session
t	Time when the session is active
e	E-mail address to obtain information about the session
r	Times when the session will be repeated
p	Phone number to obtain information about the session
m	Media line
c	Connection information
i	Information about a media line

2.3.3  RoHC健壮性报头压缩协议

在LTE中，为了在分组交换域(PS)提供语音业务且到达接近常规电路交换域的效率，必须对IP/UDP/RTP报头进行压缩。对于话音数据包，其包长较小，封装成IP包后，采用头压缩技术能有效提高频谱利用率，对于视频业务数据包，同样压缩后也可以提高频谱效率。在LTE系统中，规定PDCP子层支持健壮性报头压缩协议(ROHC)来进行报头压缩，并且同时支持IPv4和IPv6。

典型的，对于一个含有32 Byte有效载荷的VoIP分组传输来说，IPv6报头增加60 Byte，IPv4报头增加40 Byte，即188%和125%的开销。为了解决这个问题，在LTE系统中PDCP子层采用ROHC报头压缩技术，可压缩成4～6个字节，即12.5%～18.8%的相对开销，从而提高了信道的效率和分组数据的有效性。

2.3.4  SPS半持续调度

     

    Semi-Persistent Scheduling，简称SPS，半永久性调度，又称为半静态调度，LTE引入SPS调度模式的主要目的是为了支持VOIP业务。SPS调度方式可以减少控制信道的资源开销和时延抖动，但会增加PDSCH的开销；VOIP业务用户语音包发送频率较大，SPS周期调度时不需要每次都发送PDCCH，减少了控制区CCE的占用量，理论上可以提高系统用户容量。

从语音业务模型上看可以知道SPS适用于语音业务，VoIP业务的状态分为激活期和静默期,在激活期，数据包的发包间隔为20ms，每个数据包的大小固定为35~47Byte。对于暂态时的数据包大小由于没有压缩，数据包大小为92Byte, 在静默期，SID包的发包间隔为160ms，每个SID包的大小固定为10~22Byte，这样规律的发送方式适用SPS调度。

总的来说，SPS就相当于给用户分配了固定的PDSCH，可以减少PDCCH占用数，但会增加PDSCH占用数，是否开启需对两者进行权衡。对于SPS的详细内容，可以参考《SPS调度-李翔》。

2.3.6  eSRVCC(Enhanced Single Radio Voice Call Continuity)

SRVCC（Single Radio Voice Call Continuity）是3GPP提出的一种VoLTE语音业务连续性方案，主要是为了解决当单射频UE 在LTE/Pre-LTE 网络和2G/3G CS 网络之间移动时，如何保证语音呼叫连续性的问题，即保证单射频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的主要区别如下：

1.SRVCC：媒体的切换点是对端网络设备（如对端UE），影响切换时长的主要因素是会话切换后需要在IMS网络中创建新的承载。

2.eSRVCC：相比于SRVCC，媒体切换点改为更靠近本端的设备。具体方案就是增加ATCF/ATGW功能实体作为媒体锚定点，无论是切换前还是切换后的会话消息都要经过ATCF（Access Transfer Control Function）/ATGW（AccessTransfer Gateway）转发。后续在发生eSRVCC切换时，只需要创建UE与ATGW之间的承载通道，对端设备与ATGW之间的媒体流还是通过原承载通道传输。这样相当于减少了SBC至SCC AS之间的时延，明显短于SRVCC方案，减少了切换时长。

3VOLTE KPI分类及定义

VOLTE测试类指标主要有三大类指标，详见下表，部分指标为VOLTE新增指标，指标具体定义可以参考下面附件：

指标分类	指标名称
资源占用类	上行RB数
	下行RB数
	上行MCS
	下行MCS
	上行终端发射功率
	GSM通话时长占比
	呼叫SRVCC切换占比
语音质量类	MoS
	BLER
	语音丢包率
	抖动
	呼叫建立时延
	IP包时延
	端到端时延
	上行速率
	下行速率
	切换中断时延
	话音挂机时延
KPI指标类	IMS附着成功率
	话音接通成功率
	掉话率
	网内切换成功率
	SRVCC切换成功率
	寻呼成功率
	平均长保时间
	紧急呼叫建立成功率
	里程掉话比

VOLTE网管KPI指标类主要如下表，目前移动集团尚未给出KPI指标具体公式，所以在后期KPI定义可能会出现更改

指标名称（中文）	指标描述
寻呼成功率	寻呼成功次数/EPC发起寻呼请求总次数
VoLTE 无线接通率	(QCI 9 E-RAB建立成功数/QCI 9 E-RAB建立请求数)*(QCI 5 E-RAB建立成功数/QCI 5 E-RAB建立请求数)*(QCI 1 E-RAB建立成功数/QCI 1 E-RAB建立请求数)*(RRC连接建立成功次数/ RRC连接建立请求次数)*100%
VoLTE 无线接通率低的小区数量	VoLTE 无线接通率<95%的小区数量，小区需要满足条件RRC连接建立请求次数大于1000次的小区
VoLTE 无线接通率低小区占比
VoLTE下行平均时延	小区下行PDCP SDU平均时延
E-RAB掉话率（语音/视频）	E-RAB异常掉线的比例，分QCI=1，QCI=2两种情况
丢包率（语音/视频）	（MO发送的RTP数据包数量-MT接收的RTP数据包数量）/MO发送的RTP数据包数量，分QCI=1，QCI2两种情况
系统内切换成功率（语音/视频）	反映eNB间S1和X2切换出成功率、eNB内切换出请求成功率整体情况，分QCI=1，QCI=2两种情况

4VOLTE信令流程

     VOLTE是基于SIP协议的语音通话，所有与IMS交互的信令全部为SIP信令，在理解VOLTE信令方面必须对SIP信令进行了解，EPC只是做为业务承载体。由于SIP信令是以加密方式传输，SIP信令只有在CN侧和终端侧才能解码，基站CDL无法记录SIP信令，同时CDL无法解码较多NAS层直传消息，所以本文中的信令说明部分不结合CDL信令进行说明；对于某些重要信令的详细解码，本文以附件方式显示，主要为CDS导出的详细解码并对重要IE进行标注解释，建议参考。

 

4.1  注册流程及重要信令详解

    SIP 提供了发现机制，如果用户要发起和另一个用户的会话，SIP 必须发现可到达目的用户的当前主机，注册将记录地址 URI 和一个或者多个联系地址相关联，这样才能进行呼叫等业务。

严格意义上说，SUBSCRIBE和NOTIFY过程不属于注册过程，但由于该过程在注册完成后紧跟着出现，所以本文将该过程放在注册流程中进行说明。用户的注销过程与注册过程相似，主要就是注销请求中,expire值为0，所以本文中不再进行单独说明，注销过程无SUBSCRIBE信令，是因为UE注册时已有SUBSCRIBE。

信令说明如下：

1、UE进行Attach，建立QCI=9的默认承载，并使用IMS APN建立PDN连接；

2、建立立QCI=5的默认承载，用于传送SIP信令；

3、UE通过QCI=5的默认承载向P-CSCF发起注册请求；

4、P-CSCF通过HSS获知用户信息不在数据库中，便向终端代理回送401 Unauthorized 质询信息，其中包含安全认证所需的令牌；

5、终端将用户标识和密码根据安全认证令牌加密后，再次用REGISTER消息报告给P-CSCF服务器；

6、P-CSCF将REGISTER 消息中的用户信息解密，验证其合法后，IMS核心网将该用户信息登记到数据库中，并向终端返回成功响应消息200 OK；

7、用户向IMS订阅注册事件包

8、服务器应答订阅成功

9、IMS服务器发送notify消息，由于订阅的用户已经注册，所以IMS服务器回应Notify消息中，状态为active，同时携带XML信息

10、终端发送Notify 200表示接收成功

注册过程测试信令载图如下：

注销过程测试信令截图如下：

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

 该信令是用于建立QCI=5的默认承载，所有SIP信令都通过QCI=5的承载传输，该信令的内容已在该信令前的RRC重配置中附带下来。

CDS导出的详细解码如下：

主要说明如下：

该信令中主要是关注QCI等级，必须是QCI=5，才能传输SIP信令，ERAB ID=6

4.1.2  REGISTER(1ST Sip Register Request)& REGISTER 401（Unauthorized）

REGISTER信令是用于网络注册，建立关联

从CDS上导出的详细解码如下：

主要说明如下：

这是用户的第一个REGISTER REQUST信令，所以鉴权方面部分内容为空，需要网络回应后才能补齐

REGISTER 401信令是用于向终端回送401 Unauthorized 质询信息，其中包含安全认证所需的令牌，令牌对应用户第一个REGISTER REQUST信令中鉴权摘要为空的部分，并指明算法，主要说明如下：

 

4.1.3  REGISTER(2nd Sip Register Request)& REGISTER 200

第二条Register信令是终端将用户标识和密码根据安全认证令牌加密后回送给服务器

CDS上导出的详细解码如下：

主要说明如下：

REGISTER 200信令是用是确认注册流程完成，并生成SIP-URI和TEL URI，3GPP TS 23.003定义了三种URI如下，VOLTE中使用了后面两种：

Alphanumeric SIP-URIs

  Example: sip:*********************

  MSISDN represented as a SIP URI:

  Example: sip:+************************;user=phone

  MSISDN represented as a Tel URI:

     Example: tel:+447700900123：

REGISTER 200信令截图如下：

4.1.4  SUBSCRIBE& NOTIFY

SUBSCRIBE是一个用来请求对方节点的当前状态以及后续状态变化的请求方法,从网络订阅消息，NOTIFY是用于向服务器请求返回当前状态消息。

VOLTE中典型的消息流如下：

如果订阅过期了，就必须发起新的SUBSCRIBE来进行订阅

SUBSCRIBE CDS信令截图如下：

SUBSCRIBE 200 CDS信令截图如下

网络通过NOTIFY向UE发送订阅的内容，UE通过NOTIFY 200确认已收到，NOTIFY的CDS信令截图如下：

4.2  语音通话流程及重要信令详解

    语音呼叫过程就是为典型的SIP通话过程，经过多个修改，基本已经定型。由于VOLTE呼叫其它通话制式的手机时，VOLTE终端侧的信令未有变化，所以本文中不会进行说明。

CDS软件信令截图如下：

呼叫流程图如下：

信令说明如下：

1．1到5，UE起呼，发送INVITE到IMS，触发RRC连接、安全模式等过程，并通过RRC重配置消息建立SRB2信令无线承载，配置测试控制，IMS开始寻呼后，发送INVITE 100（TRYING）给UE，响应INVITE消息，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码等；

2．6到13，核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户，被叫UE收到寻呼后，触发RRC连接、安全模式等过程，被叫通过RRC重配置消息建立SRB2信令无线承载，CN侧通过QCI=5的RB向被叫发送INVITE消息，UE收到后发送INVITE 100消息进行响应，同时被叫发送INVITE 183消息给CN表示会话正在处理，启动Precondition(资源预留)过程，并通知主叫自己所支持的媒体类型和编码，并建立起QCI=1的承载；

3. 14到15，IMS收到被叫的INVITE 83 后，对主叫启动Precondition(资源预留)过程，通过EPC通知主叫SM层建立起QCI=1的承载后，向UE发送INVITE 183消息；

4． 16到23，主叫向被叫发送PRACK消息，PRACK过程是一个预确认过程，主要为了防止会话超时及拥塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，发送UPDATE消息，进行媒体格式协商过程，被叫通过UPDATE 200返回协商结果；

5. 24到29是振铃接听过程，被叫发送INVITE 180给主叫，振铃，摘机后发送INVITE 200给主叫，主叫返回ACK进行确认，通话完全建立，进入通话过程；

6. 通话结束后，主叫发送BYE请求结束本次会话，IMS服务器给被叫发送BYE,请求结束本次会话，被叫挂机，回BYE 200消息，核心网IMS服务器给主叫发BYE 200，标明会话结束，主被叫分别通过RRCConntctionReconfiguration消息和去激活EPS专用承载消息，删除QCI=1的数据无线承载。

4.2.1  INVITE

INVITE是发起会话邀请，在VOLTE中就是用于起呼，INVITE消息中主要包含了主叫信息、被叫号码和主叫支持的格式

信令截图如下：

4.2.2  RRCConnectionReconfiguration （QCI=1）

该信令对应流程中的步骤13、14的RRCConnectionReconfiguration，在核心网下发“Activate Dedicated EPS Bearer Context Request”消息后，基站将该消息附加在“RRCConnectionReconfiguration”消息中一起下发，所以“RRCConnectionReconfiguration”中解码出来的“Activate Dedicated EPS Bearer Context Request”消息内容，与后续的“Activate Dedicated EPS Bearer Context Request”消息内容一致，RRCConnectionReconfiguration在CDS上导出的详细解码如下：

主要说明如下：

1.在pdcp-Config headerCompression可以查到头压缩的的相关配置，主要内容为头压缩使用的方案格式；

2.在mac-MainConfig节点下可以查到ttiBundling功能是否开启；

3.在该消息中如果查不到关于SPS的IE，则说明SPS为关闭状态；

如果SPS开启，SPS在信令中的格式如下：

4.2.3  UPDATE & UPDATE 200

UPDATE主要是用于在呼叫过程中进行媒体格式的二次协商，UPDATE 200消息是对UPDATE消息的确认，UPDATE 200消息中协商结果为双方通话使用的通话格式，通常选取主被叫双方中格式中较低的一种，主被叫双方根据协商结果，通过“Modify EPS Bearer Context Request”消息对EPS承载进行相应的修改。

在UPDATE消息中携带了主要建议的语音编码格式，好点正常语音业务上下行各占用2个PRB左右，标清语音和高清语音资源占用基本相同，但差点标清PRB占用数会少一些，未来移动也有可能推广标清语音。

在收到的UPDATE 200消息中的编码格式为最终格式，截图如下：

如果呼叫2/3G、固话等，协商结果为2/3G、固定电话的编码为准，例如下图中为呼叫2G的UPDATE 200消息，协商结果使用AMR-NB的编码格式

4.2.4  视频通话流程与语音通话流程的异同

视频电话与语音通话过程基本相同，其中最主要的区别是需要建立QCI=1和QCI=2的承载，QCI=1传送语音，QCI=2传送视频，视频电话的信令截图如下,其中需要注意的是正常结束后会去激活两个承载。

主要区别如下：

1、语音业务INVITE消息中，呼叫的原因为语音，只携带支持的语音编码格式，视频业务的INVITE中呼叫原因为视频，并携带了主叫支持的视频编码格式。    

2、视频业务需要建立两条业务承载，QCI=1和QCI=2,这与3G的视频电视只建议一个承载不同，同时视频业务释放时需要释放两条承载；

4.3  eSRVCC切换及重要信令详解

VOLTE系统内切换与R8/9的切换相同，所以本文只针对eSRVCC切换流程进行说明；SRVCC切换流程在3GPP协议TS 23.216里定义，有多种SRVCC流程，本文介绍的是“SRVCC from E-UTRAN to GERAN without DTM support ”流程。eSRVCC切换过程比较简单，与TD-SCDMA中的CS系统间切换流程相似，通过对比可以加深理解。eSRVCC的主要流程为A2 B2 HO RELEASE，目前移动公司的策略是从LTE切向GERAN，本文只说明LTE向GERAN的SRVCC切换过程。

测试软件UU口信令截图如下：

CDL解码截图如下：

信令流程如下：

信令说明只说明UU口和S1口的信令，其它步骤详细说明见本节最后面的附件或查询 TS 23.216的6.2.2.1，主要说明如下：

1、步骤1 UE上报B2报告，基站会发起切换判决，这里有两个注意事项，必须UE和CN侧均支持SRVCC切换，基站RRM才会有步骤2判决进行SRVCC切换，否则判决为重定向，详见本文4.3.1；

2、 步骤3 eNodeB向源MME发送Handover Required消息，该消息中包含括Target ID（多为CGI）、generic Source to Target Transparent Container、 SRVCC切换指示等。SRVCC HO 指标标明切换目标只是CS域；

3、步骤 14和15，MME和目标MSC、IMS等经过一系统交互过程后，完成PS到CS的转换过程及目标小区资源预留后，MME向eNodeB发送 Handover Command， eNodeB通过MobilityFromEUTRACommand通知UE进行切换。

4、步骤16到18，UE切换到GSM,进行同步过程，同步后UE发现Suspend过程，对GPRS业务挂起，后续CN侧会数据业务挂起及通知MME进行链路释放等一系列过程，切换完成。

如果在CS 语音结束后UE还在GERAN(or for any other reason specified in TS 24.008), UE则需要按照TS 23.060规定恢复PS业务. GN SGSN将按照TS 23.060 规定恢复PDP上下文， S4 SGSN将按照TS 23.060 规定恢复承载，并且通知S- GW和P-GW(s)恢复暂停的承载；如果UE在CS语音呼叫终止后已经返回到E-UTRAN，则UE必须通过发送TAU向MME恢复PS服务， MME将通知S-GW and P-GW(s)恢复挂起的承载，恢复在S-GW和P-GW中挂起的承载，应该通过使用某种操作触发Modify Bearer request消息进行隐式恢复，例如RAU、TAU 或Service Request。S- GW知道承载的暂停状态，并且将转发Modify Bearer request消息到P- GW，如果Modify Bearer Request不是由某类操作触发时，直接恢复必须使用恢复指示消息。

4.3.1  Attach Request& Initial Context Setup Request

 Attach Request信令与Attach过程中的 Initial Context Setup Request信令分别包含了UE和网络的SRVCC能力，这是进行SRVCC的必要条件。

 下面从CDS上导出的Attach Request信令详细解码

主要说明如下：

从Attach Request信令中可以得到UE对SRVCC的能力，消息中其它内容与平常的信令相同，UE将 SRVCC capability indication作为“UE Network Capability”的一部分包含在Attach Request message/Tacking Area updaterequest中发送给MME

Initial Context Setup Request：注意该消息必须是在Attach过程中的消息才携带SRVCC能力部分。

注意事项：

1、SRVCC与SIM卡签约业务有关，HSS向MME指示UE的签约信息（STN-SR）是否支持SRVCC

5测试案例

6.1  异系统门限参考参数不合理导致无法eSRVCC切换

【问题现象】

      福州 VOLTE某一eSRVCC切换用例测试中，发现经常出现上报B2 MR基站未有下发MobilityFromEutraCommand的问题，导致无法切换；该用例测试时是由室外进入室内，RSRP逐渐衰减到一定程度，进行eSRVCC切换，切换到GERAN小区。

【问题分析】

对问题分析可能原因有三个：

  1、目标小区不合理或资源不足等原因，导致HO Require被拒；

  2、基站版本问题，对MR处理存在异常；

3、切换判决参数不合理，导致上报MR后达不到要求，不判决切换。

逐一对可能原因进行排查

1、将UE锁在GSM，测试发现配置的频点为最优频点，提取CDL进行分析，对比多次通话过程的B2 MR，发现均为上报MR后基站不判决切换，而非判决切换后HO Require被拒，排除第1个可能原因；

2、提高B2本系统门限，由-118dBm改为-105dBm，在靠近门口向窗边移动，发现可以顺利切换，多次测试均正常；在门口直接向室内最靠里位置移动时，同样会出上报B2不切换问题，所以基本排除基站对MR处理异常问题，最大可能性为切换判决参数问题。

3、将多个成功切换的B2 MR结果与未判决切换的B2事件进行对比，发现正常切换时的GERAN小区RSSI都大于30（-80dBm），未判决切换的B2 MR中，GERAN小区的RSSI均小于30，判断为异系统小区门限判断参数导致无法切换；咨询公司SE关于eSRVCC切换异系统门限的判决参数，回复为eSRVCC切换判决时，不只参考B2中的GERAN门限，同时参考“向Geran进行CCO或NACC的门限”，与“LTE向Geran CCO或NACC开关”是否打开无关。查看“向Geran进行CCO或NACC的门限”，参数设置为30，将参数修改0后，测试切换正常。

【问题解决】

  目前版本需要将“向Geran进行CCO或NACC的门限”参数设置为0，后续V3版本中已取消参考此参数。

6.2 核心网EPS承载未释放导致下次视频业务接入失败

【问题现象】

视频业务验证过程中，首次视频业务建立成功挂断后，在紧接着的视频寻呼总是接入失败（失败原因是Server Internal Error）。

【问题分析】

视频业务建立时激活了QCI-1和QCI-2两条专载：

正常的Volte业务挂断流程：终端发起业务释放后，核心网会释放对应的DRB和EPS专载。

视频业务释放时终端收到Bye并回复了Bye200，在随后RRC-Connection-Reconfiguration消息中携带的NAS信令只释放了QCI-1对应的EPS承载，没有释放QCI-2对应的EPS承载。

eNB在S1口收到了ERAB建立信令，把QCI-1和QCI-2对应的两条ERAB建立起来，然后在S1口就没有收到过其他信令。直到很久以后在16:09:32收到一个原因是Deattch的UE上下文释放命令。终端被Bye信令释放的时间点对应在eNB Log中应该在16:09:16左右。

在下一次视频业务接入时，核心网回复Invite500，原因为：Server Internal Error。

由上述分析可知，在第一次视频业务释放流程中，核心网未释放EPS承载导致了下一次视频寻呼的接入失败。

【问题解决】

在测试中的暂时解决方案为开启飞行模式，强制终端进行Detach流程，让网络和终端把相关的资源释放，后续需与CN侧定位解决。

6.3 核心网和终端协商速率过低导致视频电话质量差

【问题现象】

终端发起视频电话业务，业务接通后发现黑屏、马赛克严重，语音通话质量良好。

【问题分析】

终端侧发起视频业务请求，主叫终端与被叫终端协商后的业务速率在UPDATE200信令中：

从SDP和H.2协议解释看，Profile-level-id决定了视频的类型和等级。其中第一个字节表示视频的类型，第三个字节表示了Level等级。

H.2对视频业务Profile分类为：Baseline、Extended、Main、High、High10、High422、High444等，如下表：

每种Profile对应的ID号(十进制)如下表：

H.2对不同的Profile下边又定义了不同的level等级：

对应于业务应用中，推荐的Profile及level等级如下：

类别	Profile	Level
实时直播	低清Baseline	1.3
	标清Baseline	3
	半高清Baseline	3.1
	全高清Baseline	4.1
存储媒体	低清Main	1.3
	标清Main	3
	半高清Main	3.1
	全高清Main	4.1
高清存储	半高清High	3.1
	全高清High	4.1

从UPDATE200信令得知：双方协商的Profile-level-id=42C01E。其中Profile id = 0x42，对应于十进制的66，表示Profile是BaseLine类型的；Level=0x1E，对应于十进制的30，表示Level Number为3，与实时直播业务的标清Baseline的要求一致。从协议的要求看Max Video Bit Rate需达到10Mbps。

实际核心网下发的激活EPS承载信令中， QCI-2对应的上下行的Maximum bit rate只有0K。按照核心网的配置，无法支持level1.3及以上等级的视频业务。

当终端协商的视频格式速率要求远大于核心网配置的业务QCI中的Maximum bit rate时，会导致视频业务质量严重下降，马赛克、黑屏等问题。

【问题解决】

核心网修改了测试SIM卡对应的Maximum bit rate参数为2Mbps后，视频业务的质量得到明显改善。