srvcc_srvcc. qci_csfb(16)

Single Radio Voice Call Continuity (SRVCC) enhancements;

Stage 2

介绍了各种eSRVCC方案的备选方案。

介绍了业务流程。

3GPP TS 23.237 V12.0.0 (2012-06)

的5.2.2 Architecture when using ATCF enhancements

明确了本文的eSRVCC方案

介绍了业务流程。

3GPP TS 24.237 V11.4.0 (2012-09)

P Multimedia Subsystem (IMS) Service Continuity;

Stage 3

介绍了流程与信令扩展的细节。

思路：引入接入侧媒体锚点，减少Remote Update的信令传输时间。

eSRVCC可视为SRVCC的升级版本（实际上 SRVCC方案与eSRVCC方案可以在一个运营商网络存）。

与SRVCC相比，新增ATCF/ATGW网元，SCC-AS功能有增强，HSS透明数据有新增。其它网元功能不变（比如MME、eMSC、UE)

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

切换的信令面变化，参见：

切换前后的信令均经过了ATCF。

媒体面的切换路径参见：

切换前后的媒体均经过了ATGW。

ATCF/ATGW:信令锚定点，媒体锚定点

从信令面来说，多了一个网元，多了一些信令传递。但由此带来的时延不大。关键是IMS 远端update过程在大多数情况下可以不做。

从媒体面来说，多了一个网元。但由于切换前后的媒体均锚定到ATGW。对远端来说看到的SDP是ATGW产生。

当ATGW SDP不变时，可以不需要Update remote end。切换时延将大大减少。

ATCF可与P-CSCF或SBC合设。

大部分呼叫是不需要update remote end的。但如果切换后，媒体类型（如audio、video）发生变化（比如2G CS域只支持audio了），或ATGW无法完成Transcoding，或ATCF发现用户有多路呼叫，则需更新远端媒体。此时ATCF发起Invite(ATU-STI)给SCC-AS。SCC-AS会关联到远端用户，并更新远端媒体。同时bye掉前面建立的呼叫leg（也是这个ATCF发过来的)

eSRVCC中，媒体的锚定在ATGW，信令的锚定由ATCF与SCC-AS共同完成（如上所述，呼叫、切换产生的新呼叫都会发到SCC-AS）。

当用户有多路呼叫时，UE切换时只发起一路呼叫的切换，即MSC只会发起一路呼叫到ATCF。 SCC-AS发现用户有多路呼叫时，会发 Refer消息给ATCF，再转发给MSC，由MSC在CS域内发起第二路呼叫。

eSRVCC业务流程

VoLTE技术中的会话持续性-ICS,SRVCC,eSRVCC85_SRVCC

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

用户在LTE侧发起注册，呼叫在LTE承载上，经过PGW发到互联网上IMS域：P-CSCF/A-SBC->ATCF->S-CSCF->SCC AS。

注册时，ATCF分配dynamic STN-SR，在注册消息中发给SCC AS， SCC AS修改IMS-HSS中用户数据，HSS将修改的数据下插到MME中，切换时带给eMSC。

注：这个过程中：SCC AS、IMS-HSS、MME的操作与SRVCC方案一样。

区别只是SRVCC中，STN-SR是SCC AS产生。而eSRVCC中，STN-SR是由ATCF产生。原因是：SRVCC中，MSC直接发切换请求给SCC AS(带STN-SR)，而eSRVCC中，MSC发切换请求给ATCF（带STN-SR) 。

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