书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

5.1.1 域选

由于支持VoLTE的UE可以有多种模式，在不同的信号强度覆盖下可以附着在不同的网络，如有时附着在2G/3G网络，有时附着在LTE网络，甚至可以同时附着于两个网络，因此，支持VoLTE的UE在呼叫时就要选择接入其中一个网络进行语音通话，选择接入网络的过程称为域选。

当作为主叫时，由UE根据保存的注册网络信息完成域选，即UE选择一个满足接入条件的无线基站及完成注册的网络进行主叫业务。

当作为被叫时，由网络侧查询用户数据库获取注册网络信息，完成域选，即当主叫用户呼叫UE时，网络侧会进行用户当前所在是CS域还是IMS域的选择，在当前网络下，CS域指的是UE接入2G/3G网络，IMS域指的是UE接入4G网络。

3GPP协议标准中，网络侧完成域选的功能实体被称为T-ADS（Terminating Access Domain Selection），T-ADS功能一般集成在SCCAS中。

1.基本概念

VoLTE的通话模型是多样化的，可以是主、被叫均为VoLTE终端，也可以一方为VoLTE终端，一方为CSFB等中端。在众多通话模型中，有两种通话模型：主叫侧在VoLTE网络，而被叫侧为CSFB用户以及驻留在CS网络的VoLTE用户，两者最终都是在CS域接听电话，那么这两种模型有什么不同呢？

这就涉及在VoLTE网络中域选的概念，主要涉及两个节点和两个选择。

（1）第一个节点S-CSCF与第一个选择ENUM。主叫流程到达第一个节点—S-CSCF，所谓“兵马未动，粮草先行”，S-CSCF并不急于转发呼叫请求，而是先“询问”ENUM，ENUM会告诉它，被叫是非VoLTE用户还是VoLTE用户并指示S-CSCF下一跳地址。如果是CSFB用户，则ENUM会指示S-CSCF把会话流程交给被叫侧的MGCF；而如果是VoLTE用户，则ENUM会指示S-CSCF把会话流程交给被叫侧的ICSCF，然后通过一系列查找转给相应的S-CSCF，如图5-1所示。

（2）第二个选择SCCAS。对于被叫侧的S-CSCF而言，它需要将Invite消息转发给SCCAS，由SCCAS来完成被叫网络域选。但SCCAS目前只知道自己的用户是VoLTE用户，并不知道驻留在哪个网络。因此，SCCAS需要再去“询问”HSS，根据HSS提供的信息来做出第二个选择——选择被叫用户目前适合在CS域还是LTE网络下通话，HSS会提供被叫用户最近注册的网络信息，由SCCAS来选择最终的域选网络，如果是CS域，则SCCAS找到被叫侧的MGCF，MGCF转发呼叫请求到第二个节点MSC，如图5-2所示。

而对于CSFB而言，流程已经走到了MGCF，于是直接转发呼叫请求到第二个节点MSC。

（3）第二个节点MSC。流程到这里已经不需要做出选择了，对于VoLTE而言，MSC已经知道被叫用户在CS域了，因此，直接通过层层转发找到被叫用户即可；但对于CSFB而言，MSC需要通知被叫用户从4G回落到2G，因此，需要先联合4G侧的MME使被叫用户回落，再完成呼叫。

2.实现方式

T-ADS域选的典型组网如图5-3所示。

（1）在域选过程中，SCCAS首先判断自己是否有被叫UE的接入域信息，如果没有，则查询数据库。对于正处于业务过程的UE来说，SCCAS会有UE的接入域信息。

（2）SCCAS发送T-ADS查询消息给HLR/HSS，HLR/HSS根据自己存储的信息决定是否向MME和SGSN发送T-ADS查询，HLR/HSS获取UE当前的接入域信息并返回SCCAS。

（3）SCCAS根据这些信息来判断UE当前所在网络，完成被叫域选。

由于当前现网绝大多数厂商的GnGp SGSN都不支持Gr（MAP协议）接口的T-ADS查询，因此，就需要通过其他方式来完成对GnGp SGSN的域选判断。一般的解决方案是通过在HLR/HSS中打开GnGp SGSN注册信息判断功能，判断是否存在GnGp SGSN注册信息，如果存在则UE在CS域，如果不存在则UE在IMS域。

3.关键点

（1）SCCAS判断是否查询用户数据库

当SCCAS收到入局Invite消息时，需要根据用户信息和网络配置判断是否向HLR/HSS查询被叫用户T-ADS信息，具体的判断原则如图5-4所示。若判断出需要查询，则向HLR/HSS发送用户T-ADS信息查询请求。

（2）HLR/HSS判断是否查询MME和SGSN

HLR/HSS收到T-ADS查询的请求消息后，根据用户在MME和SGSN上的注册情况和网络配置，判断是否向MME和SGSN查询用户的T-ADS信息，具体判断原则如表5-1所示。如果满足判断条件，则根据对应动作进行下一步处理。

（3）SCCAS判断域选网络

SCCAS收到HLR/HSS返回的UDA消息，并根据消息中携带的T-ADS信息判断域选到哪个网络，具体判断原则如图5-5所示。

4.实现过程

以融合HLR/HSS场景为例说明T-ADS域选的实现过程，SCCAS通过Sh接口查询融合HLR/HSS，获取用户T-ADS信息。

典型组网如图5-6所示，消息流程如图5-7所示。

流程1～2：I/S-CSCF收到入局Invite消息，根据用户的iFC模板数据，触发SCCAS。

流程3：SCCAS根据判断原则判断是否向融合HLR/HSS查询被叫用户的接入域选择T-ADS信息（SCCAS查询融合HLR/HSS是为了判断域选到哪个网络，如果在查询融合HLR/HSS之前就能判断域选到哪个网络，则无须发起查询）。

流程4：SCCAS向融合HLR/HSS发送UDR消息，请求获取被叫用户的T-ADS信息。UDR消息如图5-8所示。

其中，关键参数如下。

· publicIdentity：携带用户标识IMPU。

· dataReference：取值为“tads”“ueSrvccCapData”等，表示请求T-ADS、UE的SRVCC能力等信息。

P1：融合HLR/HSS收到UDR消息后，根据被叫用户在GnGp SGSN上的注册情况，按照判断原则判断是否查询MME，以获取被叫用户的T-ADS信息。

流程5～6：若P1中判断出需要查询MME，则融合HLR/HSS通过IDR消息向MME查询被叫用户的T-ADS信息。

流程7：融合HLR/HSS根据MME返回的IDA消息将T-ADS信息通过UDA消息返回给SCCAS。

IDA消息如图5-9所示。

其中，关键参数如下。

· ims-voice-over-ps-sessions-supported：指示当前用户所在网络是否支持PS语音。

· last-ue-activity-time：指示UE最近一次活动时间。

· rat-type：指示接入网类型。

注：如果返回的IDA消息中未携带上述三个参数，则融合HLR/HSS认为该T-ADS信息无效。

融合HLR/HSS判断流程如表5-2所示。

融合HLR/HSS返回UDA消息给SCCAS，其中包含的T-ADS信息示例如下。

其中，关键参数如下。

· IMSVoiceOverPSSessionSupport：表示用户当前附着网络是否支持PS语音。

· 0：表示不支持。

· 1：表示支持。

· 2：表示能力未知。

· RATtype：表示用户当前附着网络类型。

· 1001：GERAN。

· 1000：UTRAN。

· 1004：EUTRAN。

· LastUEActivityTime：表示用户在当前附着网络上最近一次活动时间。

流程8：SCCAS基于获取的T-ADS信息，根据T-ADS域选原则判断域选哪个网络。

流程9：SCCAS确定被叫域选的网络后，通过在Invite消息中携带特定头域指示S-CSCF将呼叫接续到特定网络。

流程10：S-CSCF根据指示将呼叫接续到特定网络的被叫用户。

5.1.2 锚定

锚定（Anchoring）是指在4G网络建设阶段，由于4G网络覆盖的范围有限，当LTE终端用户漫游到只有2G/3G网络的覆盖时，无法正常享受到IMS网络提供的业务。于是，通过锚定的方式，将在CS网络接入下的用户锚定到IMS网络进行业务处理，从而为用户提供IMS业务服务。同样，2G/3G用户也可以通过锚定的方式接入到IMS网络，享受IMS网络提供的补充业务和智能业务。

1.场景分类

锚定方案分为主叫锚定和被叫锚定，其应用场景如下。

（1）被叫锚定

被叫用户在CS网络接入，且签约了IMS网络业务，或被叫用户在LTE网络接入，当呼叫入局到GMSC Server时，则需要通过锚定功能将呼叫请求路由到IMS网络进行被叫业务触发。

VoLTE用户为被叫时，既有可能位于TD-LTE/EPC/IMS网络，又有可能位于2G/3G网络；如果VoLTE用户从2G/3G用户转为VoLTE用户时采取的是不更换MSISDN手机号码策略，即VoLTE用户与2G/3G用户混用MSISDN号码，则主叫局无法仅根据被叫MSISDN号码决定后续呼叫路由，且无法保证被叫VoLTE用户补充业务体验一致性，故引入被叫锚定方案。

（2）主叫锚定

主叫用户在CS网络接入，且签约了IMS网络业务，则需要通过锚定功能将呼叫请求路由到IMS网络进行主叫业务触发。

考虑到主叫用户的补充业务在现网比较少，现网一般采取主叫不锚定、被叫锚定策略，这里主要讲述被叫锚定的基本原理和实现流程。

2.基本原理

被叫锚定是指当CS域用户呼叫VoLTE用户时，需要将被叫用户的业务控制权从CS域锚定回IMS域。

GMSC（CS域寻址被叫用户的交换机）根据在HLR中签约的T-CSI触发到锚定服务器上获取IMRN，将呼叫路由到IMS，T-CSI是基于单用户签约的数据。

IMRN获取方式支持号段方式和前缀方式。

（1）IMRN号段方式

Anchor AS在规划的IMRN号段中分配一个IMRN，并以IMRN作为索引存储本次锚定的呼叫信息。当呼叫路由到IMS网络后，由Anchor AS根据IMRN完成呼叫信息和被叫号码的还原。

IMRN是IMS网络规划的E.164号码，由“路由+随机索引”部分组成。例如，路由部分是“86755”，随机索引部分在“001～999”取值，即IMRN号码在“86755001～86755999”随机取值。

（2）IMRN前缀方式

Anchor AS在原被叫号码前增加IMRN锚定前缀，在进入IMS网络前，由MGCF删除锚定前缀，完成被叫号码的还原，或者在呼叫路由到IMS网络后，由Anchor AS根据IMRN和主叫号码完成呼叫信息和被叫号码的还原。

IMRN号码的组成形式为“+CC（国家码）-被叫锚定前缀-NDC（国内目的码）-SN（用户号码）”。例如：被叫号码为861390001，锚定前缀为123，则Anchor AS通过前缀方式分配的IMRN号码为861231390001。

两种方式的优缺点对比如表5-3所示。

一般现网选择的是IMRN前缀方式。

3.实现流程

如图5-10所示，业务锚定的实现流程如下。

流程1～2：用户A呼叫用户B，GMSC服务器向HLR发送SRI消息，HLR判断签约数据包含T-CSI，则将T-CSI通过SRI RSP消息返回给GMSC服务器，其中携带Anchor AS地址。

流程3：GMSC服务器发送IDP消息到Anchor AS，智能获取IMRN号码，Anchor AS通过Connect消息返回IMRN。

流程4～5：GMSC服务器根据IMRN将呼叫请求路由到MGCF，MGCF根据IMRN将呼叫请求路由到I-CSCF，在出局前，MGCF将被叫锚定前缀删除，完成被叫号码的还原。其中，Route头域未携带“orig”参数。

流程6：由于Invite消息未携带“orig”参数，I-CSCF识别为被叫流程，I-CSCF向IMS-HSS发送LIR消息，为用户A选择一个可以提供服务的S-CSCF。

流程7～9：I-CSCF发送呼叫请求到S-CSCF，S-CSCF根据本地保存的锚定用户签约iFC模板数据，触发其他AS。其他AS触发业务后，S-CSCF将呼叫请求路由到SCCAS，完成T-ADS域选处理。

5.1.3 SRVCC

1.基本概念

单一无线语音呼叫连续（SRVCC，Single Radio Voice Call Continuity）业务是指用户在通话过程中从E-UTRAN（Evolved Universal Terrestrial Radio Access Network）漫游到UTRAN（UMTS Terrestrial Radio Access Network）/GERAN（GSM EDGE Radio Access Network）时，经过UE和网络设备的切换过程，保持用户的通话不中断。

SRVCC切换分为bSRVCC（振铃前SRVCC）、aSRVCC（振铃中SRVCC）、eSRVCC（增强型SRVCC）等，如表5-4所示。

当终端和网络都支持vSRVCC后，视频呼叫才可以支持SRVCC切换。

当终端和网络都支持rSRVCC后，终端才能够在通话状态下由2G/3G网络切换回LTE网络。

网元会根据自己掌握的信息做出判断，并执行当前版本所支持的转接类型，也许这种转接最后的结果会掉话（比如SCCAS把b当成a，至于到底是b还是a，取决于网元的具体实现逻辑，它能够处理就好，强制在全局做出一个严格的认定可能并没有现实的意义）。

SCCAS已经收到180，则可以确定是aSRVCC，但是SCCAS的逻辑是，振铃必须在双方资源预留完成之后。因为有彩铃业务过程的存在，之后SCCAS又收到Update（更新消息），此时Remote侧（远端）的资源还没有完成预留，如果此时发生SRVCC，SCCAS会认为是bSRVCC。

除了彩铃，呼叫等待也会发生类似的情况，因为它们都是先Update再返回180。SCCAS在主叫侧返回的183中携带了Feature-Caps信息，这表明支持aSRVCC但不支持bSRVCC，因此发送取消会话，携带原因为“No appropriate session for SRVCC/eSRVCC”的信息。

2.解决方案

在LTE没有发展到完全覆盖阶段，要保持语音业务的连续性，也就是单射频UE在IMS控制的VoIP语音和CS语音之间的无缝切换。与其他切换技术比较，SRVCC切换方案（目前商用为增强型eSRVCC方案）更加成熟，为大多数主流运营商所采用，但需要部署IMS及升级改造EPC相关网元、为保证语音业务连续性（如表5-5所示），当通话过程中离开LTE覆盖区，SRVCC（Single Radio Voice Call Continuity）作为VoLTE的关键技术，其主要处理单射频UE在LTE网络和2G/3G网络之间移动的情况。

SRVCC包括EPC、CS以及IMS三大模块，为了实现不中断的语音呼叫，需要三个模块协同工作。其中，电路域的MSC需要升级为增强的MSC（eMSC），以便支持从MME发来的切换过程，支持IMS到CS的切换并关联CS切换和从IMS域到CS域的域转移；EPC中的MME需要从PS承载中分离出语音和非语音部分，对语音承载部分发起SRVCC切换，非语音承载可进行PS—PS切换、挂起或局间传递。

3.业务流程

SRVCC切换也是为了让用户享受到一个连续的语音清晰的业务，当LTE信号覆盖全面时，是不需要做SRVCC切换的，只要做LTE系统内切换即可，这和传统切换一样。当LTE覆盖有空洞时，就需要SRVCC切换来弥补语音业务连续性的问题，由于VoLTE业务的特性，从LTE网络到2G/3G网络切换时需要将接入域的相关信息告知IMS业务控制域，由此SRVCC的切换过程相对较为复杂。

（1）SRVCC切换流程如图5-11所示，简要描述如下。

① eNB根据测量报告发起向UTRAN/GERAN的SRVCC切换过程。

② MME发送PS到CS的切换请求到Enhanced MSC（eMSC）。

③ Enhanced MSC向目的MSC发起切换准备消息。

④ MSC向UTRAN/GERAN发送切换请求，接收响应。

⑤ 建立eMSC和MSC之间的承载。

⑥ Enhanced MSC向IMS域发起会话建立请求并路由到SCCAS。

⑦ SCCAS发起新会话到远端用户，并将媒体流切换到MGW上。

⑧ SCCAS释放IMS会话分支（旧会话资源）。

⑨ eMSC返回切换响应经MME给eNB，eNB发送切换命令给用户。

⑩ 终端接入UTRAN/GERAN，与目的MSC建立承载。

SRVCC切换前后的信令和承载修改过程如图5-12所示。

（2）eSRVCC切换流程

eSRVCC切换流程可以简单地分为以下三个部分。

① 切换判断。

eNB根据UE上传的测量报告（包括E-UTRAN网络下的小区信号测量报告以及邻近的UTRAN/GERAN网络的信号测量报告），判断是否进行接入网切换。

② 切换准备。

a.eNB判断需要切换接入网后，向源MME发送Handover Required消息。MME根据消息中的eSRVCC指示，将QCI=1的语音承载和其他承载分离，同时根据切换请求消息中的Target ID选择一个SRVCC IWF，通过Sv接口向其发起PS to CS Request切换请求。该消息中携带了C-MSISDN以及之前ATCF为UE分配的STN-SR号码。

b.SRVCC IWF收到切换请求消息后，根据消息中携带的Target ID，找到目标MSC服务器（切换目标侧所属MSC服务器），然后在SRVCC IWF和目标MSC服务器间执行切换流程。目标侧UTRAN/GERAN网络的承载建立完成后，SRVCC IWF根据STN-SR号码，建立SRVCC IWF和ATCF/ATGW的承载。

c.ATCF根据C-MSISDN关联用户待切换的会话，更新ATGW上的承载信息，将本端媒体面切换为UTRAN/GERAN网络的承载，并通知SCCAS更新UE的接入域信息。

③ 切换后的处理：由于用户之前未在UTRAN/GERAN网络附着，切换完成后，在呼叫未释放前，SRVCC IWF代替用户发起到CS域HLR的位置更新，确保后续的呼叫能正确地路由到被叫。

eSRVCC切换前后的信令和承载修改过程如图5-13所示。

切换前的信令传送路径示意：本端UE—LTE基站—4G核心网—ATCF—IMS核心网（包含SCCAS）—远端UE。

切换前的媒体传送路径示意：本端UE—4G基站—4G核心网—ATGW—远端UE。

切换后的信令传送路径示意：本端UE—2G或3G基站—CS域核心网—e-MSC—ATCF—IMS核心网（包含SCCAS）—远端UE。

切换后的媒体传送路径示意：本端UE—2G或3G基站—CS域核心网—MGW—ATGW—远端UE。

4.关键参数

（1）STN-SR，会话转移号码（SRVCC，Session Transfer Number for SRVCC）。如果当前网络支持SRVCC特性，则在用户签约时，由SAE-HSS为其分配一个STN-SR号码。该号码用于SRVCC IWF寻址SCCAS，请求从PS域到CS域的会话切换。如果当前网络支持eSRVCC，则由ATCF分配STN-SR号码，替换掉SAE-HSS上签约的STN-SR号码，即在eSRVCC流程中，STN-SR用于SRVCC-IWF寻址ATCF，使切换后的会话和远端会话在ATCF/ATGW上关联。

（2）C-MSISDN，关联的MSISDN（Correlation MSISDN）。如果当前网络支持SRVCC/eSRVCC特性，则在用户签约时，由HSS为其分配一个C-MSISDN号码。该号码与用户的MSISDN号码关联，用于SCCAS（SRVCC特性）或ATCF（eSRVCC特性）匹配用户当前待切换的会话。在实际使用中，C-MSISDN即为用户的MSISDN。

（3）ATU-STI（Access Transfer Update - Session Transfer Identifier，接入切换会话更新标识）。在eSRVCC特性中，该号码由SCCAS分配，用于切换过程中ATCF寻址SCCAS。

（4）Mid-call切换，指会话处于保持（Hold）状态时，Hold业务方发生SRVCC/eSRVCC切换（用户A保持连接用户B，用户A发生切换）。

（5）振铃态切换，指会话的一方处于振铃状态，尚未应答，本方或另外一方发生SRVCC/eSRVCC切换。

（6）激活状态会话，指被叫UE已经应答的会话，即主、被叫其中一方已经发送或接收了2xx响应的会话。

（7）激活的语音媒体成分，指UE上存在着属性为“Recvonly”或者“Sendrecv”的语音媒体。

（8）最近一个激活状态，且具有激活的语音媒体成分的会话，指UE上最近已经应答的，且存在着属性为“Recvonly”或者“Sendrecv”的语音媒体。

例如，用户A呼叫用户B，然后用户A保持连接用户B。此时用户A和用户B的会话中用户A的媒体属性为“Sendonly”。之后，用户A呼叫用户C，用户C应答。此时用户A和用户C的会话对于用户A而言，就是“最近一个激活状态，且具有激活的语音媒体成分的会话”。

在eSRVCC切换中，当SRVCC IWF向ATCF发起切换请求时，ATCF通过C-MSISDN关联用户“最近一个激活状态，且具有激活的语音媒体成分的会话”，进行SDP协商和修改，并向SCCAS发起此会话的切换请求。

5.时延特性

语音业务从基于IMS的VoLTE切换到2G/3G的CS域，以保证语音业务的连续性，此过程即为SRVCC。

（1）单信道语音连续（Signal Radio Voice Call Continuity）业务SRVCC，为使用LTE接入的IMS语音服务网络提供单信道语音连续性解决方案。SRVCC在UE从LTE移动到CS时，建立CS域呼叫分支，并通过SCCAS锚点将CS分支和原IMS到呼叫对端分支连接，从而形成完整的呼叫链，保证IMS域呼叫能够在切换后继续进行。通过SRVCC方案，4G终端可以通过单信道模式，从LTE切换到CS。

（2）eSRVCC（Enhanced SRVCC），在SRVCC的基础上，增加ATCF网元，作为SCCAS的前置网元，替代SCCAS作为信令面锚点。和ATCF网元配合的还有ATGW网元，其作为媒体面锚点使用。这从以下两个方面优化了SRVCC。

① ATCF位于服务网络，而SCCAS位于归属网络，ATCF更接近终端，减少了MSC到IMS的承载建立时间。

② 增加的ATGW作为媒体面锚点，避免到远端的对端分支更新（Remote Leg Update）过程，这样可以提高切换成功率，同时降低切换时间。

（3）eSRVCC切换时延。SRVCC方案切换中断时延大，切换性能有待提升，R10定义的eSRVCC方案相对于SRVCC方案的增强在于减少了切换时长（切换时长小于300ms），使用户获得更好的通话体验，进一步提升了切换性能、降低了业务中断时延；SRVCC媒体的切换点是对端网络设备（如对端UE），影响切换时长的主要因素是会话切换后需要在IMS网络中创建新的承载。

SRVCC与eSRVCC从切换流程来看基本类似，在网络架构（如图5-14所示）方面，后者相比于前者新增的ATCF/ATGW网元主要功能是优化了切换时延，如图5-15所示。

SRVCC技术采用归属地SCCAS网元作为信令/媒体锚点，而在eSRVCC组网中新增加了ATCF（Access Transfer Control Function）/ATGW（Access Transfer Gateway）逻辑网元作为本地信令/媒体锚点，使eSRVCC媒体切换点更靠近本端的设备，经过IMS域的所有会话都锚定在ATCF上，只需要创建UE与ATGW之间的承载通道，对端设备与ATGW之间的媒体流还是通过原承载通道传输，这样其创建新承载通道的消息交互路径明显短于SRVCC方案，可有效减少切换时长，避免语音中断情况的发生。在呼叫从EPC切换到CS后，增加MSC和ATCF交互，完成会话切换。ATCF是逻辑网元，3GPP标准规定其可以部署在P-CSCF、IBCF、MSCS等网元中。

终端不区分SRVCC和eSRVCC，均看作SRVCC，附着过程中终端上报SRVCC能力，并存储在HSS中；是否支持eSRVCC是由拜访地和归属地的网络部署决定的，只有当拜访地和归属地均支持eSRVCC时，终端才能进行eSRVCC切换，否则执行SRVCC切换。

5.1.4 CS Retry

5.1.4.1 基本概念

VoLTE用户作为被叫用户，且呼叫被域选到IMS域后，由于被叫终端不在IMS域内或专用承载建立失败等原因而导致该呼叫不能在IMS域被接续，SCCAS支持尝试从CS域进行接续。

CS Retry流程分为以下两种情况。

（1）CS Retry普通流程。

SCCAS在没有收到被叫的18X消息时收到OXX响应，或者没有收到任何消息，但CS Retry定时器超时后触发CS Retry流程。

（2）专有承载建立失败下的CS Retry流程。

SCCAS在已经收到了18X消息以后，收到特定的OXX消息或等待200（for Update）响应，CS Retry定时器超时后触发CS Retry流程。

说明：

① 触发CS Retry的原因值一般包括400（未发现目的号码）、404、408（请求超时）、410（离线）、480（暂时不可达）、488、500、503（服务器不可达）、504（服务超时）、580。

② CS Retry定时器推荐配置为EPC网络寻呼时长加1～2s。一般来说，现网MME配置的寻呼次数为3，CS Retry定时器时长要大于MME设置的总寻呼时长，如图5-16所示。

5.1.4.2 CS Retry普通流程

CS Retry普通流程如图5-17所示。

主要描述被叫侧的呼叫请求流程，如图5-18所示。

具体呼叫流程见以下1、2、3～5、6a～8a或6b～8b、9～11。

流程1：UE_A呼叫UE_B，向用户提供业务的IMS网络的I-CSCF收到Invite消息。

流程2：I-CSCF收到请求（Invite）消息后，做如下处理。

· I-CSCF向融合HLR/HSS中的IMS-HSS发送LIR消息，请求获取为用户B注册的S-CSCF地址。

· IMS-HSS向I-CSCF返回LIA响应，携带S-CSCF地址。

· I-CSCF经过S-CSCF将Invite消息发到SCCAS。

流程3～5: SCCAS将Invite消息从IMS域通过SBC尝试发给UE_B。其后触发CS Retry的处理流程取决于CS Retry定时器。

· 当定时器未超时，SCCAS收到480消息→6a～8a。

· 当定时器超时，SCCAS未收到480消息→6b～8b。

SCCAS在触发CS Retry后将Invite消息中的PANI头域修改为3PTC，用于指示S-CSCF直接将呼叫接续至UE_B。

备注：触发CS Retry的SIP状态码可以在SCCAS网元上的参数“触发CS Retry的SIP状态码”进行配置，这里以SIP状态码480为例。

流程6a～8a：SCCAS收到480消息后，停掉CS Retry定时器。在确认触发CS Retry的SIP状态码为480后，SCCAS触发CS Retry，将被叫侧呼叫域选结果改为CS域，并将Invite消息落地在CS域，再转步骤9。

流程6b～8b：SCCAS发送取消（Cancel）消息给UE_B，并将域选结果修改为CS域的Invite消息落地在CS域，再转步骤9。

流程9～11：SCCAS指示呼叫重新域选到CS域，Invite消息落地到CS域之后的流程同基本呼叫中的域选到CS域的流程相同。

针对上面流程中的P1、P2、P3、P4、P5分别做出详细解释。

P1：SCCAS收到Invite消息后，进行T-ADS域选。只有在同时满足VoLTE用户B做被叫时候域选的结果为IMS域且SCCAS上开启了“CS Retry的开关”时，SCCAS才启动CS Retry定时器，否则，不能触发CS Retry。

P2：呼叫请求到达被叫终端，但是被叫终端当前不可用，不接受PS域的呼叫，回复480消息。

P3：SCCAS收到480消息后，是否结束IMS域的智能业务，需要判断“CS Retry后是否触发智能业务”功能的取值。

（1）如果取值为“Yes”，且IMS域存在智能业务，则需要结束当前IMS域的所有智能业务，否则，不做处理。

（2）如果取值为“No”，则不做处理。

P4：SCCAS发送Cancel消息前，是否结束IMS域的智能业务，需要判断“CS Retry后是否触发智能业务”功能的取值。

（1）如果取值为“Yes”，判断如果IMS域存在智能业务，则需要结束当前IMS域的所有智能业务，否则不做处理。

（2）如果取值为“No”，则不做处理。

SCCAS将呼叫接续到CS网络之前，需要进行抑制重复锚定处理，具体有如下两种方式。

（1）CSRN路由方式

SCCAS设置T-CSI抑制信元，向融合HLR/HSS发送UDR消息，通过融合HLR/HSS获取用户的CSRN号码（MSRN号码），指示S-CSCF将呼叫路由到CS网络。

（2）CIC路由方式

SCCAS在主叫号码前增加CIC前缀，在被叫号码后增加CIC参数。Request-URI中被叫号码的CIC参数用于指示S-CSCF将呼叫路由到CS网络，P-Asserted-Identity中主叫号码前的CIC前缀用于抑制呼叫请求重复锚定到IMS网络。当呼叫路由到MGCF后，由MGCF根据CIC前缀设置T-CSI抑制信元，并查询向HLR获取用户的MSRN号码。

这里以CIC路由方式为例。域选结果修改为CS域的Invite消息示例如下。

其中，“cic=261”指示S-CSCF将呼叫路由到MGCF。

P5：在将呼叫重新域选到CS域后，如果此处满足智能触发条件，则需要触发智能业务，此时触发的智能业务为CS Retry后CS域触发的智能业务。

5.1.4.3 专有承载建立失败下的CS Retry流程

SCCAS在收到了18X消息后，收到特定的OXX消息或等待200（for Update）响应CS Retry定时器超时后触发的CS Retry流程。由于现网专有承载建立时一般都有资源预留过程，所以专有承载建立失败的CS Retry流程分为以下三种场景。

1.资源预留过程中，终端感知建立专有承载失败

本场景主要描述被叫侧的呼叫请求流程，如图5-19所示。

流程1～5：SCCAS_B收到来自UE_A的Invite消息后，进行T-ADS域选。只有在同时满足VoLTE用户UE_B做被叫时候域选的结果为IMS域且SCCAS上开启了“CS Retry的开关”时，SCCAS启动CS Retry定时器，否则，不能触发CS Retry流程。

流程6～13：被叫建立专有承载时，SCCAS_B收到183消息，因为启用了资源预留流程，这时终端如果感知到建立专有承载失败，会上报580消息。

流程14～17：SCCAS_B向MGCF发送不带SDP的Invite消息到CS域，MGCF返回带SDP的183消息。

流程18～19：UE_A向SCCAS_B发送Update消息。

流程20～21：SCCAS_B直接给主叫侧回送200消息，携带UE_B上次协商的SDP_B。至此，上个资源预留流程协商已完成。

流程22～23：SCCAS_B发送Update消息给主叫侧进行媒体修改。

流程24～27：主叫侧返回200消息以后，SCCAS_B给MGCF回送Prack消息。

流程28～29：被叫侧返回200消息完成对Prack消息的确认。

针对上面流程中的P1、P2、P3、P4分别做出详细解释。

P1：SCCAS_B收到580消息以后，如果CS Retry功能中“收到183后是否触发CS Retry”相关参数配置为“Yes”，且CS Retry功能中的收到183后触发CS Retry的状态码包含580，则启动CS Retry流程。

P2：MGCF返回的183消息带了SDP以后，SCCAS_B需要先缓存此消息，等待前面的资源预留流程结束。

P3：SCCAS_B收到主叫侧的Update消息以后，代理UE_B完成上个资源预留流程的协商。

P4：SCCAS_B发起新的媒体协商。

特别说明：

如果SCCAS_B先收到了主叫侧的Update消息，这时SCCAS_B会给SBC_B发送Update消息，SBC_B会给UE_B发送Update消息，但是SCCAS_B不会收到来自UE_B/SBC_B的200消息。这时如果SCCAS_B收到580消息，处理与上述流程类似，此处不再赘述。

2.资源预留过程中，SBC感知建立专有承载

失败本场景主要描述被叫侧的呼叫请求流程，如图5-20所示。

此场景下，SBC_B在183消息时建立承载，感知到承载建立失败后向SCCAS_B发送503消息。对于SCCAS_B而言，与在资源预留过程中终端感知建立专有承载失败下的CS Retry流程相比，仅是收到触发CS Retry的消息发生了变化（580消息替换为503消息），此处不再重复描述。

3.资源预留过程中，等待200响应超时

本场景主要描述被叫侧的呼叫请求流程，如图5-21所示。

流程1～5：SCCAS_B收到来自UE_A的Invite消息后，进行T-ADS域选。当同时满足VoLTE用户UE_B做被叫时候域选的结果为IMS且SCCAS上开启了“CS Retry的开关”时，SCCAS启动CS Retry定时器，否则，不能触发CS Retry流程。

流程6～14：被叫侧向UE_A发送183消息，UE_A向被叫侧发送Update消息进行媒体协商。

流程15～16：定时器超时后，SCCAS_B触发CS Retry流程，向SBC_B发送Cancel消息。

流程17～18：SCCAS_B直接给主叫侧回送200消息，携带UE_B上次协商的SDP_B消息。至此，上个资源预留流程协商已完成。

流程19～22：SCCAS_B向MGCF发送不带SDP的Invite消息到CS域重试，MGCF返回带SDP的183消息。

流程23～24：SCCAS_B发送Update消息给主叫侧进行媒体修改。

流程25～28：主叫侧返回200消息以后，SCCAS_B给MGCF回送Prack消息。

流程29～30：被叫侧返回200消息完成对Prack消息的确认。

针对上面流程中的P1、P2、P3、P4分别做出详细解释。

P1～P2：SCCAS_B收到来自主叫侧的Update消息后，进行如下处理。

① 如果在SCCAS中将“资源预留下Update响应超时触发CS Retry”配置为“Yes”，则SCCAS_B在发送Update消息以后，启动Update响应定时器（定时器一般设置为5s）等待后发送200 OK消息。

② 如果定时器超时未收到任何消息（如果收到503等消息也可引起CS Retry，这种情形在资源预留过程中，SBC感知建立专有承载失败下的CS Retry流程中已有描述），则启动CS Retry流程。

P3：SCCAS_B代理UE_B完成上个资源预留流程的协商。

P4：SCCAS_B发起新的媒体协商。

5.1.4.4 呼叫特点

VoLTE中典型的场景是CS和VoLTE共号，用户在CS域或LTE漫游情况下，实现基本呼叫的路由，进行接入域的选择并正确找到被叫。

VoLTE的基本呼叫流程是路由的流程，包含不同的终端类型在不同的网络结构下适用的基本呼叫流程。

终端根据设置选择网络是CS还是IMS。

1.作主叫时，由终端根据保存的注册网络信息选择接入网络；

终端在Attach或TAU的请求中会将自身的设置信息带给网络，具体字段为“Voice domain preference and UE’s usage setting”。

其中，

（1）Voice domain preference for E-UTRAN字段含义如下。

（2）UE’s usage setting字段含义如下。

① Voice Centric表示UE支持IMS语音业务，或CSFB语音业务，或两者都支持。Voice Centric的终端必须保证语音业务可用，假如在LTE网络中无法获得语音业务（IMS Voice和CSFB都不可用）时，终端必须去使能E-UTRAN能力，重选回GERAN或UTRAN网络。

② Data centric表示不需要保证语音业务可用，假如在LTE网络中无法获得语音业务（IMS Voice和CSFB都不可用）时，终端仍可以继续工作在E-UTRAN网络中，此时语音业务不可用。

目前VoLTE终端的设置如下。

2.作为被叫时，由网络侧查询数据库选择终端的接入网络。

5.1.4.5 签约数据

VoLTE用户的基本标识是IMSI和MSISDN，其在IMS网络的用户标识IMPI、IMPU、T-IMPU均由IMSI和MSISDN推导。

IMSI：GSM/UMTS/EPC网络中用于唯一识别移动用户的号码，该号码用于移动用户在网络中的注册和鉴权。

MSISDN：GSM/UMTS/EPC网络中呼叫一个移动用户所需拨打的号码。

IMPI：IMS网络中用于唯一识别一个终端，该标识用于IMS用户在IMS网络中的注册和鉴权。

IMPU：IMPU在IMS网络中用于实际通信和号码显示的标识。IMPU有两种形式：SIP URI和Tel URI。

T-IMPU：在IMS-HSS上设置为闭锁，仅用于用户的注册，不用于发起业务，对其他用户不可见。