VoLTE原理简介
项目名称 |
|
文档编号 |
|
版 本 号 |
|
部 门 | 专业服务部 |
作 者 |
|
版权所有
大唐移动通信设备有限公司
本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权,任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容,违者将被依法追究责任。
文档更新记录
日期
| 更新人
| 版本
| 备注
|
2014-11-19
| 苏晓群
| 1.0.0
| 创建文档
|
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
技术优势... 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
系统架构... 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
健壮性报头压缩协议... 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
半持续调度... 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无法执行... 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小区主要参数配置及测试信令进行详细说明,使读者对VOLTE有个基本的了解;由于VOLTE现在未商用,所以实际优化经验较少,优化可以参考R9及2/3G的优化经验。
1.2预期读者和阅读建议本文档预期读者为网络技术优化人员、系统测试人员等。
1.3参考资料[1]
《TD-LTE半持续调度特性实现报告》
[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技术背景
目前业界对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*640
720P/1080P possible
| 分辨率:176*144
|
频谱效率
| 仿真测试结果显示:同样承载AMR,LTE的频谱效率可达到R993倍以上 |
2.2VOLTE系统架构
VOLTE采用IMS作为业务控制层系统,EPC仅作为承载层;要求终端、无线网络、分组域、电路域和IMS域端到端的技术配合以实现基于IMS的分组域语音和多媒体业务。SRVCC切换解决了语音连续性问题,呼叫时延短,无需回落2G/3G发起语音,避免频繁网间重选。VOTLE网络框架图如下:
中移动二阶段VOLTE福州测试的网络拓朴如下:
VOLTE的协议架构如下图,从图中可以看到,SIP协议只在终端和IMS支持,对于无线接入网只是一个透传做用:

2.3VOLTE关键技术
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、QCI5、QCI 8/9,视频电话业务共使用QCI 1、QCI 2、QCI 5、QCI 8/9。
QCI | 资源类型(Resource Type) | 优先级(Priority) | 时延
(Packet Delay Budget) | 丢包率(PacketError Loss ate)
| 典型业务(ExampleServices)
| |
|
1 | GBR | 2 | 100 ms | 10-2
| VOIP | |
2 | 4 | 150 ms | 10-3
| 电话会议, 会话视频(直播流媒体) | |
3 | 3 | 50 ms | 10-3
| 实时在线游戏, 实时工业监控 | |
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
| 视频(直播流媒体), 话音业务 | |
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协议是互联网行业标准组织IETF提出的,SIP(Session Initiation Protocol)是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播(multicast)、网状单播(unicast)或两者的混合体进行通信。VoLTE选择了SIP协议,最主要的原因就是免费。
在VOLTE中引入了IMS,对VOLTE进行业务控制,MME只是做为业务的承载体,IMS对业务的控制全部通过SIP消息完成,在学习VoLTE的过程中必须学习SIP消息。
SIP有两种类型的消息,它们是:
(1)
请求:从客户机发到服务器的消息。
(2)
响应:从服务器发到客户机的消息。
其中VOLTE常用的请求消息包括下列几种,表中也列出了消息的定义文档:
SIP方法
| 描述
| 定义文档
|
INVITE
| 表示一个客户端发起或被邀请参加电话会议(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
| 终止一个呼叫,可以由主叫或被叫方发起(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服务器发起地址列表注册(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
| 向订阅都发送一个新的事件(Notify thesubscriber of a new Event)
| RFC3265
|
UPDATE
| 在没有修改对话状态的情况下修改会话(Modifies the state of a session withoutchanging the state of the dialog)
| RFC3311
|
PUBLISH
| 发布一个事件到服务器(Publishes an event to the Server)
| RFC3903
|
INFO
| 会话过程中发送一个会话消息,但不修改会话状态(Sendsmid-session information that does not modify the session state)
| RFC6086
|
REFER
| 请求收件人发出SIP请求(Asks recipient to issue SIP request(call transfer))
| RFC3515
|
MESSAGE
| 使用SIP传输即时消息(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
| 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健壮性报头压缩协议
在LTE中,为了在分组交换域(PS)提供语音业务且到达接近常规电路交换域的效率,必须对IP/UDP/RTP报头进行压缩。对于话音数据包,其包长较小,封装成IP包后,采用头压缩技术能有效提高频谱利用率,对于视频业务数据包,同样压缩后也可以提高频谱效率。在LTE系统中,规定PDCP子层支持健壮性报头压缩协议(ROHC)来进行报头压缩,并且同时支持IPv4和IPv6。
典型的,对于一个含有32 Byte有效载荷的VoIP分组传输来说,IPv6报头增加60Byte,IPv4报头增加40 Byte,即188%和125%的开销。为了解决这个问题,在LTE系统中PDCP子层采用ROHC报头压缩技术,可压缩成4~6个字节,即12.5%~18.8%的相对开销,从而提高了信道的效率和分组数据的有效性。
2.3.5SPS半持续调度
Semi-PersistentScheduling,简称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.6eSRVCC(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方案,减少了切换时长。
3
VOLTE KPI分类及定义
VOLTE测试类指标主要有三大类指标,详见下表,部分指标为VOLTE新增指标,指标具体定义可以参考下面附件:
指标分类 | 指标名称 |
资源占用类 | 上行RB数 |
下行RB数 |
上行MCS |
下行MCS |
上行终端发射功率 |
GSM通话时长占比 |
呼叫SRVCC切换占比 |
语音质量类 | MoS |
BLER |
语音丢包率 |
抖动 |
呼叫建立时延 |
IP包时延 |
端到端时延 |
上行速率 |
下行速率 |
切换中断时延 |
话音挂机时延 |
KPI指标类 | IMS附着成功率 |
话音接通成功率 |
掉话率 |
网内切换成功率 |
SRVCC切换成功率 |
寻呼成功率 |
平均长保时间 |
紧急呼叫建立成功率 |
里程掉话比 |
VOLTE网管KPI指标类主要如下表:
指标项
| 单位
| 说明
|
ERAB建立和RRC建立
|
|
|
LTE_ERAB.ErabEstabSuccRate.Qci1
| %
| LTE_会话类语音业务ERAB建立成功率_Qci1
|
LTE_ERAB.ErabEstabSuccRate.Qci2
| %
| LTE_会话类直播视频流业务ERAB建立成功率_Qci2
|
LTE_ERAB.ErabEstabSuccRate.Qci5
| %
| LTE_IMS信令业务ERAB建立成功率_Qci5
|
LTE_RRC.VoLteRadioConnSuccRate
| %
| VoLTE无线接通率(QCI=1)
|
LTE_RRC.ConvVideoCallSuccRate
| %
| LTE_会话类直播视频流业务无线接通率_Qci2
|
LTE_RRC.ImsSigCallSuccRate
| %
| LTE_IMS信令业务无线接通率_Qci5
|
掉线
|
|
|
ERAB掉线率QCI五
| %
| 目前OMC预定义指标没有
|
ERAB掉线率QCI一
| %
| 目前OMC预定义指标没有
|
ERAB掉线率QCI九
| %
| 目前OMC预定义指标没有
|
ERAB掉线率QCI二
| %
| 目前OMC预定义指标没有
|
LTE_ERAB.ImsSigCallDropRatio
| %
| LTE_IMS信令业务无线掉线率_Qci5
|
LTE_ERAB.ImsSigCallDropRate
| %
| LTE_IMS信令业务无线掉线率_Qci5_小区级
|
LTE_ERAB.OthersCallDropRate
| %
| LTE_其他类业务无线掉线率_Qci9_小区级
|
LTE_ERAB.OthersCallDropRatio
| %
| LTE_其他类业务无线掉线率_Qci9
|
LTE_ERAB.ConvVoiceCallDropRatio
| %
| LTE_会话类语音业务无线掉话率_Qci1
|
LTE_ERAB.ConvVideoCallDropRate
| %
| LTE_会话类直播视频流业务无线掉话率_Qci2_小区级
|
LTE_ERAB.ConvVoiceCallDropRate
| %
| LTE_会话类语音业务无线掉话率_Qci1_小区级
|
LTE_ERAB.ConvVideoCallDropRatio
| %
| LTE_会话类直播视频流业务无线掉话率_Qci2
|
上下行时延
|
|
|
LTE_PDCP.UpPktDelayDl.Qci1
| 毫秒
| 分QCI的小区用户面下行平均时延-QCI1
|
LTE_PDCP.UpPktDelayDl.Qci5
| 毫秒
| 分QCI的小区用户面下行平均时延-QCI5
|
LTE_PDCP.UpPktDelayDl.Qci2
| 毫秒
| 分QCI的小区用户面下行平均时延-QCI2
|
LTE_PDCP.UpPktDelayDl.Qci9
| 毫秒
| 分QCI的小区用户面下行平均时延-QCI9
|
LTE_PDCP.VoLteUpPktDiscardRateDl
| 百万分之一
| VoLTE下行弃包率
|
LTE_PDCP.VoLteUpPktLossRateDl
| 百万分之一
| VoLTE下行丢包率
|
LTE_PDCP.VoLteUpPktLossRateUl
| 百万分之一
| VoLTE上行丢包率
|
4
VOLTE信令流程
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的默认承载向IMS发起注册请求;
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.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)®ISTER 401(Unauthorized)
REGISTER
信令是用于网络注册,建立关联
从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是一个用来请求对方节点的当前状态以及后续状态变化的请求方法,从网络订阅消息,NOTIFY是用于向服务器请求返回当前状态消息。
VOLTE中典型的消息流如下:

如果订阅过期了,就必须发起新的SUBSCRIBE来进行订阅
SUBSCRIBE CDS信令截图如下:
SUBSCRIBE 200 CDS信令截图如下
网络通过NOTIFY向UE发送订阅的内容,UE通过NOTIFY 200确认已收到,NOTIFY的CDS信令截图如下:
4.2语音通话流程及重要信令详解
语音呼叫过程就是为典型的SIP通话过程,经过多个修改,基本已经定型。由于VOLTE呼叫其它通话制式的手机时,VOLTE终端侧的信令未有变化,所以本文中不会进行说明。
CDS软件信令截图如下:
呼叫流程图如下:
信令说明如下:
1.1到6,UE起呼,UE高层协议层需要发送INVITE到IMS,触发RRC连接、安全模式等过程,并通过RRC重配置消息建立SRB2信令无线承载、恢复QCI 5承载,配置测量控制,IMS收到主叫的INITE消息,开始寻呼,并发送INVITE 100(TRYING)给主叫UE,用于响应INVITE消息,INVITE消息中包含呼叫类型、主被叫的号码、主叫方支持的媒体类型和编码等;
2.7到15,核心网向处于空闲态的被叫发INVITE消息,由于被叫处于空闲态,所以核心网侧触发寻呼消息,寻呼处于空闲态的被叫用户,被叫UE收到寻呼后,触发RRC连接、安全模式等过程,被叫通过RRC重配置消息建立SRB2信令无线承载,CN侧通过QCI=5的RB向被叫发送INVITE消息,UE收到后发送INVITE 100消息进行响应,同时被叫发送INVITE 183消息给CN表示会话正在处理,启动Precondition(资源预留)过程,并通知主叫自己所支持的媒体类型和编码,并建立起QCI=1的承载;
3. 16到17,IMS收到被叫的INVITE 83后,对主叫启动Precondition(资源预留)过程,通过EPC通知主叫SM层建立起QCI=1的承载后,向UE发送INVITE 183消息;
4.18到25,主叫向被叫发送PRACK消息,PRACK过程是一个预确认过程,主要为了防止会话超时及拥塞,被叫收到后返回PRACK200,主叫收到被叫的PRACK 200以后,发送UPDATE消息,进行媒体格式协商过程,被叫通过UPDATE 200返回协商结果;
5. 26到31是振铃接听过程,被叫发送INVITE 180给主叫,振铃,摘机后发送INVITE 200给主叫,主叫返回ACK进行确认,通话完全建立,进入通话过程;
6. 32到37为挂机过程 ,通话结束后,主叫发送BYE请求结束本次会话,IMS服务器给被叫发送BYE,请求结束本次会话,被叫挂机,回BYE 200消息,核心网IMS服务器给主叫发BYE 200,标明会话结束,主被叫分别去激活EPS专用承载消息,删除QCI=1的数据无线承载。
4.2.1INVITE
INVITE是发起会话邀请,在VOLTE中就是用于起呼,INVITE消息中主要包含了主叫信息、被叫号码和主叫支持的格式
信令截图如下:

4.2.2RRCConnectionReconfiguration (QCI=1)
该信令对应流程中的步骤13、14的RRCConnectionReconfiguration,在核心网下发“Activate Dedicated EPS Bearer Context Request”消息后,基站将该消息附加在“RRCConnectionReconfiguration”消息中一起下发,所以“RRCConnectionReconfiguration”中解码出来的“ActivateDedicated EPS Bearer Context Request”消息内容,与后续的“ActivateDedicated EPS Bearer Context Request”消息内容一致,RRCConnectionReconfiguration在CDS上导出的详细解码如下:
主要说明如下:
1.
在pdcp-ConfigàheaderCompression可以查到头压缩的的相关配置,主要内容为头压缩使用的方案格式;
2.
在mac-MainConfig节点下可以查到ttiBundling功能是否开启;
3.
在该消息中如果查不到关于SPS的IE,则说明SPS为关闭状态;
如果SPS开启,SPS在信令中的格式如下:

4.2.3UPDATE & 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.3eSRVCC切换及重要信令详解
VOLTE系统内切换与R8/9的切换相同,所以本文只针对eSRVCC切换流程进行说明;SRVCC切换流程在3GPP协议TS 23.216里定义,有多种SRVCC流程,本文介绍的是“SRVCC from E-UTRAN to GERANwithout 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 TransparentContainer、 SRVCC切换指示等。SRVCC HO 指标标明切换目标只是CS域;
3、
步骤 14和15,MME和目标MSC、IMS等经过一系统交互过程后,完成PS到CS的转换过程及目标小区资源预留后,MME向eNodeB发送 HandoverCommand, eNodeB通过MobilityFromEUTRACommand通知UE进行切换。
4、
步骤16到18,UE切换到GSM,进行同步过程,同步后UE发现Suspend过程,对GPRS业务挂起,后续CN侧会数据业务挂起及通知MME进行链路释放等一系列过程,切换完成。
如果在CS 语音结束后UE还在GERAN(or for any other reason specifiedin TS 24.008), UE则需要按照TS 23.060规定恢复PS业务. GN SGSN将按照TS23.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 或ServiceRequest。S- GW知道承载的暂停状态,并且将转发ModifyBearer request消息到P- GW,如果ModifyBearer Request不是由某类操作触发时,直接恢复必须使用恢复指示消息。

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
中发送给MME

Initial Context Setup Request
:注意该消息必须是在Attach过程中的消息才携带SRVCC能力部分。
注意事项:
1、SRVCC与SIM卡签约业务有关,HSS
向MME
指示UE
的签约信息(STN-SR
)是否支持SRVCC
5
常见问题案例
6.1SIM卡无VoLTE权限导致注册失败
【问题现象】
浙江丽水项目在市移动公司申请4张,均IMS注册失败,导致无法进行VOLTE业务测试。
【问题分析】
1、
UE ATTACH过程正常,已建立QCI 9的默认承载,如下图所示,APN为CMNE
2、UE发起APN为IMS的PDN连接请求后,MME下发第二个默认承载的建立请求,正常情况下建立QCI 5的默认承载,而MME实际下发的是QCI 9的承载建立,且APN仍为CMNET的APN,导致建立失败,从而导致无法进行IMS注册过程,下图中左边为正常PDN连接请求后下发QCI 5默认承载建立的信令解码,右边部分为异常解码。
怀疑可能有以下两个原因导致:
1、
SIM 卡无VOLTE权限;
2、
PGW的P-CSCF发现功能部份设置错误
【问题解决】
经市公司核查后得知,地市公司无权限开通VOLTE测试卡,导致所开通的SIM无法注册,已向省公司重新申请SIM卡。
6.2
SIM授权问题导致eSRVCC无法执行【问题现象】
在VOLTE测试过程中发现在RSRP变差到-110以后不能切换到2G而是重定向到2G,这样不符合规范,MOS值会中断,再次呼叫会引起未接通,从下图复测过程中可以看到上报B2以后不是正常的发起eSRVCC切换流程而是直接Release(重定向)。
【问题分析】
在该区域多次进行测试发现依旧如此,更换终端以后进行测试还是会重定向到2G,怀疑是否是基站参数问题,对基站参数进行检查并没有发现异常设置,对比能正常切换的流程,少了RRM判决系统间切换的过程,基站版本是6.10.24,是否是基站RRM判决异常还是参数原因
更换SIM进行验证以后发现可以正常的进行eSRVCC切换,怀疑是SIM授权出现问题,对比信令流程发现在上下文建立请求中核心网没有带SRVCC能力,而正常的流程中携带有SRVCC能力如下图:
不携带SRVCC能力:
携带SRVCC能力:
【问题解决】
大规模上VOLTE部署以后如果遇到此类问题建议首先确认SIM卡的授权SRVCC功能是否正常。
6.3
广东云浮项目呼叫建立时延过长【问题现象】
广东云浮项目VOLTE测试,呼叫建立时延可长达5-8S,比2、3G建立时延还长
【问题分析】
1、主叫发了INVITE后,到IMS开始寻呼用了0.4S,但是被叫在4秒后才收到寻呼,怀疑HSS在查找被叫号码时时间过久
2、主叫先于被叫建立QCI1专载,和规范流程不合,正常只有IMS处理有问题才会这样
【问题解决】
将问题反映给地市移动公司,要求协调核查HSS与IMS是否部署完毕,移动最后反馈,云浮暂时挂靠在深圳的测试IMS上,HSS为广州HSS,均在调试阶段,未正式投入使用,性能还不能达到正常使用程度,需调试完成后才能解决。