VoLTE基础信令流程与详细解析.docx

VoLTE基础信令流程与详细解析.docx

《VoLTE基础信令流程与详细解析.docx》由会员分享，可在线阅读，更多相关《VoLTE基础信令流程与详细解析.docx（22页珍藏版）》请在冰豆网上搜索。

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的默认承载，并使用IMSAPN建立PDN连接；

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

3.UE通过QCI=5的默认承载向IMS发起注册请求；

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

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

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

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

8.服务器应答订阅成功

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

10.终端发送Notify200表示接收成功

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

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

1）ActivateDefaultEPSBearerContextRequest（QCI=5）

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

主要说明如下：

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

2）REGISTER（1STSipRegisterRequest）®ISTER401（Unauthorized）

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

主要说明如下：

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

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

3）REGISTER（2ndSipRegisterRequest）®ISTER200

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

主要说明如下：

REGISTER200信令是用是确认注册流程完成，并生成SIP-URI和TELURI，3GPPTS23.003定义了三种URI如下，VOLTE中使用了后面两种：

AlphanumericSIP-URIs

Example:

sip:

MSISDNrepresentedasaSIPURI:

Example:

sip:

+;user=phone

MSISDNrepresentedasaTelURI:

Example:

tel:

+447700900123：

REGISTER200信令截图如下：

4）SUBSCRIBE&NOTIFY

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

VOLTE中典型的消息流如下：

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

SUBSCRIBECDS信令截图如下：

SUBSCRIBE200CDS信令截图如下

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

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

语音呼叫过程就是为典型的SIP通话过程，经过多个修改，基本已经定型。

由于VOLTE呼叫其它通话制式的手机时，VOLTE终端侧的信令未有变化，所以本文中不会进行说明。

CDS软件信令截图如下：

呼叫流程图如下：

信令说明如下：

1．1到6，UE起呼，UE高层协议层需要发送INVITE到IMS，触发RRC连接、安全模式等过程，并通过RRC重配置消息建立SRB2信令无线承载、恢复QCI5承载，配置测量控制，IMS收到主叫的INITE消息，开始寻呼，并发送INVITE100（TRYING）给主叫UE，用于响应INVITE消息，INVITE消息中包含呼叫类型、主被叫的号码、主叫方支持的媒体类型和编码等；

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

3.16到17，IMS收到被叫的INVITE83后，对主叫启动Precondition（资源预留）过程，通过EPC通知主叫SM层建立起QCI=1的承载后，向UE发送INVITE183消息；

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

5.26到31是振铃接听过程，被叫发送INVITE180给主叫，振铃，摘机后发送INVITE200给主叫，主叫返回ACK进行确认，通话完全建立，进入通话过程；

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

5）INVITE

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

信令截图如下：

6）RRCConnectionReconfiguration（QCI=1）

该信令对应流程中的步骤13、14的RRCConnectionReconfiguration，在核心网下发“ActivateDedicatedEPSBearerContextRequest”消息后，基站将该消息附加在“RRCConnectionReconfiguration”消息中一起下发，所以“RRCConnectionReconfiguration”中解码出来的“ActivateDedicatedEPSBearerContextRequest”消息内容，与后续的“ActivateDedicatedEPSBearerContextRequest”消息内容一致。

主要说明如下：

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

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

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

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

7）UPDATE&UPDATE200

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

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

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

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

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

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

主要区别如下：

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

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

3.eSRVCC切换及重要信令详解

VOLTE系统内切换与R8/9的切换相同，所以本文只针对eSRVCC切换流程进行说明；SRVCC切换流程在3GPP协议TS23.216里定义，有多种SRVCC流程，本文介绍的是“SRVCCfromE-UTRANtoGERANwithoutDTMsupport”流程。

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

eSRVCC的主要流程为A2→B2→HO→RELEASE，目前移动公司的策略是从LTE切向GERAN，本文只说明LTE向GERAN的SRVCC切换过程。

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

CDL解码截图如下：

信令流程如下：

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

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

17.步骤3eNodeB向源MME发送HandoverRequired消息，该消息中包含括TargetID（多为CGI）、genericSourcetoTargetTransparentContainer、SRVCC切换指示等。

SRVCCHO指标标明切换目标只是CS域；

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

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

如果在CS语音结束后UE还在GERAN（orforanyotherreasonspecifiedinTS 24.008）,UE则需要按照TS 23.060规定恢复PS业务.GNSGSN将按照TS23.060规定恢复PDP上下文，S4SGSN将按照TS23.060规定恢复承载，并且通知S-GW和P-GW（s）恢复暂停的承载；如果UE在CS语音呼叫终止后已经返回到E-UTRAN，则UE必须通过发送TAU向MME恢复PS服务，MME将通知S-GWandP-GW（s）恢复挂起的承载，恢复在S-GW和P-GW中挂起的承载，应该通过使用某种操作触发ModifyBearerrequest消息进行隐式恢复，例如RAU、TAU或ServiceRequest。

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

9）AttachRequest&InitialContextSetupRequest

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

主要说明如下：

从AttachRequest信令中可以得到UE对SRVCC的能力，消息中其它内容与平常的信令相同，UE将SRVCCcapabilityindication作为“UENetworkCapability”的一部分包含在AttachRequestmessage/TackingAreaupdaterequest中发送给MME

InitialContextSetupRequest：

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

注意事项：

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