VoLTE基础信令流程与详细解析之欧阳地创编

VOLTE信令流程
VOLTE是基于SIP协议的语音通话，所有与IMS交互的信令全部为SIP信令，在理解VOLTE信令方面必须对SIP信令进行了解，EPC只是做为业务承载体。

由于SIP 信令是以加密方式传输，SIP信令只有在CN侧和终端侧才能解码，基站CDL无法记录SIP信令，同时CDL无法解码较多NAS层直传消息，所以本文中的信令说明部分不结合CDL信令进行说明
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.PCSCF通过HSS获知用户信息不在数据库中，
便向终端代理回送401Unauthorized质询信息，其中包含安全认证所需的令牌；
5.终端将用户标识和密码根据安全认证令牌加密
后，再次用REGISTER消息报告给PCSCF服务器；
6.PCSCF将REGISTER 消息中的用户信息解密，
验证其合法后，IMS核心网将该用户信息登记到数据库中，并向终端返回成功响应消息200 OK；
7.用户向IMS订阅注册事件包
8.服务器应答订阅成功
9.IMS服务器发送notify消息，由于订阅的用
户已经注册，所以IMS服务器回应Notify消息中，
状态为active，同时携带XML信息
10.终端发送Notify 200表示接收成功
注册过程测试信令载图如下：
注销过程测试信令截图如下：
1)Activate??Default??EPS??Bearer??Context??Requ
est（QCI????）
该信令是用于建立QCI????的默认承载，所有SIP信令都通过QCI????的承载传输，该信令的内容已在该信令前的RRC重配置中附带下来。

主要说明如下：
该信令中主要是关注QCI等级，必须是QCI????，才能传输SIP信令，ERAB??ID????
2)REGISTER ST??Sip??Register??Request??2:15??
REGISTER????
（Unauthorized）
REGISTER信令是用于网络注册，建立关联
主要说明如下：
这是用户的第一个REGISTER??REQUST信令，所以鉴权方面部分内容为空，需要网络回应后才能补齐REGISTER????
信令是用于向终端回送??
Unauthorized??质询信息，其中包含安全认证所需的令牌，令牌对应用户第一个REGISTER??REQUST信令中鉴权摘要为空的部分，并指明算法，主要说明如下：
3)REGISTER(2nd Sip Register Request)&REGISTER
200
第二条Register信令是终端将用户标识和密码根据安全认证令牌加密后回送给服务器
主要说明如下：
REGISTER 200信令是用是确认注册流程完成，并生成SIPURI和TEL URI，3GPP TS 23.003定义了三种URI 如下，VOLTE中使用了后面两种：
Alphanumeric SIPURIs
Example: sip:voicemail@
MSISDN represented as a SIP URI:
Example: sip:+447700900123@;user=phone
MSISDN represented as a Tel URI:
Example: tel:+447700900123：
REGISTER 200信令截图如下：
4)SUBSCRIBE&NOTIFY
SUBSCRIBE是一个用来请求对方节点的当前状态以及后续状态变化的请求方法,从网络订阅消息，NOTIFY是用于向服务器请求返回当前状态消息。

VOLTE中典型的消息流如下：
如果订阅过期了，就必须发起新的SUBSCRIBE来进行订阅
SUBSCRIBE CDS信令截图如下：
SUBSCRIBE 200 CDS信令截图如下
网络通过NOTIFY向UE发送订阅的内容，UE通过NOTIFY 200确认已收到，NOTIFY的CDS信令截图如下：
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过程是一个预确认过程，主要为了防止会话超时及拥塞，被叫收到后返回PRACK 200，主叫收到被叫的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的数据无线承载。

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

信令截图如下：
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”消息内容一致。

主要说明如下：
1.在pdcpConfig headerCompression可以查到头压
缩的的相关配置，主要内容为头压缩使用的方案格
式；
2.在macMainConfig节点下可以查到ttiBundling功
能是否开启；
3.在该消息中如果查不到关于SPS的IE，则说明SPS
为关闭状态；
如果SPS开启，SPS在信令中的格式如下：
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消息，协商结果使用AMRNB的编码格式
4)视频通话流程与语音通话流程的异同
视频电话与语音通话过程基本相同，其中最主要的区别是需要建立QCI=1和QCI=2的承载，QCI=1传送语音，QCI=2传送视频，视频电话的信令截图如下,其中需要注意的是正常结束后会去激活两个承载。

主要区别如下：
1.语音业务INVITE消息中，呼叫的原因为语音，只携
带支持的语音编码格式，视频业务的INVITE中呼叫原因为视频，并携带了主叫支持的视频编码格式。

2.视频业务需要建立两条业务承载，QCI=1和QCI=2,
这与3G的视频电视只建议一个承载不同，同时视频
业务释放时需要释放两条承载；
3.eSRVCC切换及重要信令详解
VOLTE系统内切换与R8/9的切换相同，所以本文只针对eSRVCC切换流程进行说明；SRVCC切换流程在3GPP 协议TS 23.216里定义，有多种SRVCC流程，本文介绍的是“SRVCC fr om EUTRAN to GERAN without DTM support”流程。

eSRVCC切换过程比较简单，与TDSCDMA 中的CS系统间切换流程相似，通过对比可以加深理解。

eSRVCC的主要流程为A2B2HO 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和PGW(s)恢复暂
停的承载；如果UE在CS语音呼叫终止后已经返回到EUTRAN，则UE必须通过发送TAU向MME恢复PS服务，MME将通知SGW and PGW(s)恢复挂起的承载，恢复在SGW 和PGW中挂起的承载，应该通过使用某种操作触发Modify Bearer request消息进行隐式恢复，例如RAU、TAU 或Service Request。

S GW知道承载的暂停状态，并且将转发Modify Bearer request消息到P GW，如果ModifyBearer Request不是由某类操作触发时，直接恢复必须使用恢复指示消息。

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

主要说明如下：
从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.1、SRVCC与SIM卡签约业务有关，HSS向MME指示
UE的签约信息（STNSR）是否支持SRVCC。