srvcc_srvcc. qci_csfb(15)

因为E-CSCF与PSAP、EC都在漫游域或用户接入地，那么紧急呼叫方案与处于home域的SCC-AS无关。

SRVCC方案引入EATF，EATF提供基于IMS实现的IMS紧急会话的业务连续性。用户漫游时，该功能实于拜访地运营商的IMS网络，提供IMS紧急会话的锚定和PS到CS的转换。EATF类似一个路由B2BUA，通过请求第三方（3pcc）的呼叫控制实现接入类型的切换。

紧急呼叫的SRVCC切换流程如下：

上图流程表示紧急呼叫的SRVCC切换过程。被叫侧开始切换接入网到CS域时，MSC在CS域代替UE-A发起域切换，被叫号码为E-STN-SR(Emergency Session Transfer Number for SR VCC) ，这个呼叫通过I-CSCF被路由到EATF，EATF把这个呼叫与用户原来连接到PSAP的那路呼叫关联起来，发送一个Reinvite给PSAP侧进行媒体交换。通过这个过程，EATF提供了紧急呼叫的会话连续性功能

紧急呼叫的SRVCC过程，与普通呼叫类似，区别是MSC发的invite带了E-STN-SR，与普通呼叫带的VDN或STN-SR不同，这样，这个呼叫不会到达S-CSCF，而是直接被I-CSCF呼到EATF了，由EATF来更新远端媒体（类似SCC AS)。

SRVCC流程的改进思路

现有流程的缺点是：

1，UE的handover过程完成后（较快）（此时UE的无线通道已经切换到CS域）。IMS侧update remote end还未完成。则远端UE仍会把RTP媒体发向LTE侧。

对远端UE来说，就是用户面中断，远端UE有一段时间会听不到对方语音。降低了远端UE的语音质量。

对于完全不知道对方是否移动的远端UE来说，可能这种语音中断更难忍受。

2，同上，总体切换时延由IMS侧update remote end过程来完成。切换时延较长，超过300ms。 对本端UE来说，切换时延较长+用户面中断，也造成自己有一段时间会听不到对方语音。降低了本端UE的语音质量。

曾经产生了各种SRVCC的优化方案，目标提高本端与远端UE的语音质量，具体针对切换时延与用户面中断两个缺点进行。

1，eMSC与接入网MSC合一，降低时延效果不明显。

2，先update remote end，再进行handover。这样对远端较好，而对本端则切换时延更长了。 3，先handover，再发起IMS切换。本端用户面不会中断，但时延更长了。

4，采用eSRVCC方案：切换前后的媒体都锚定到同一个ATGW，大多数呼叫情况下不需要进行IMS侧的update remote end。充分降低了切换时延

在 3GPP TR 23.856 的 7.2 Assessment of alternatives 中列出各种eSRVCC方案。

3. VoLTE技术中的会话持续性-eSRVCC

目录

eSRVCC方案对于SRVCC方案的改进及标准

信令面、媒体面在切换前后的路径

eSRVCC业务流程

一、用户注册流程：STN-SR，ATU-STI，C-MSISDN

二、用户呼叫流程：正常的IMS呼叫，但必须控制锚定媒体到ATGW

三、eSRVCC切换流程：STN-SR，ATU-STI，C-MSISDN

其它技术点

IMS-HSS新增数据项

控制非SRVCC用户呼叫不需经过ATCF的方法

缓存8秒的过程

eSRVCC是否兼容SRVCC

eSRVCC的缺点

========

eSRVCC方案对于SRVCC方案的改进及标准

3GPP TR 23.856

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-32538-15.html