VoLTE端到端业务详解 | VoLTE基本概念

Posted COCOgsta

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了VoLTE端到端业务详解 | VoLTE基本概念相关的知识,希望对你有一定的参考价值。

书籍来源:艾怀丽《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上设置为闭锁,仅用于用户的注册,不用于发起业务,对其他用户不可见。

以上是关于VoLTE端到端业务详解 | VoLTE基本概念的主要内容,如果未能解决你的问题,请参考以下文章

VoLTE端到端业务详解 | 基本概念

VoLTE端到端业务详解 | 掉话问题

VoLTE端到端业务详解 | 高清语音的概念

VoLTE端到端业务详解 | 基本原理

VoLTE端到端业务详解 | 接通问题

VoLTE端到端业务详解 | 空口主要特性功能