SRVCC是3GPP提出的一种VoLTE语音业务连续性方案，主要是为解决当单射频UE 在LTE 网络和2G/3G CS 网络之间移动时，如何保证语音呼叫连续性的问题，即保证单射频UE 在VoLTE 语音和CS 域语音之间的平滑切换。
一、STN-SR产生背景
LTE开网初期网络覆盖不足，用户在使用VOLTE语音通话过程中，随着用户的移动，离开LTE覆盖范围后，正在进行的语音业务面临掉话问题。为解决这一问题3GPP在R9版本引入了SRVCC方案。
在R9 SRVCC方案中，切换的控制锚点位于归属地SCC AS(Service Centralization and Continuity Application Server)上，很容易导致切换时长超过300ms，影响终端用户体验。而3GPP在R10版本推出了eSRVCC方案，将切换锚点前移至访问地的ATCF（Access Transfer Control Function）/ATGW（Access Transfer Gateway）上。
这样当发生eSRVCC切换时，只需要创建UE与ATGW之间的承载通道，对端设备与ATGW之间的媒体流还是通过原承载通道传输。这样就大大减少切换时长，使用户获得更好的通话体验。
图表1.eSRVCC切换前后信令及承载通道
在eSRVCC中一个很关键的参数就是STN-SR(Session Transfer Number - Single Radio)。它用来在发生eSRVCC切换时，帮助MSC正确的找到对应的ATCF，完成切换。
二、STN-SR格式
STN-SR是一个E.164格式的路由号码，用来标识处理SRVCC切换的IMS节点。在eSRVCC里，它用来标识用户在IMS注册登记时关联的ATCF节点，当发生eSRVCC切换时MSC将使用从EPC域的MME处获得的STN-SR号码，来向IMS域的ATCF寻址，并发起SRVCC切换请求，请求将媒体承载路径从LTE PS切换到CS(这种支持与MME间Sv接口的MSC，也被称为eMSC（Enhanced MSC）。
图表2. STN-SR生成及应用网元
三、STN-SR生成使用三步曲
STN-SR生成和使用主要涉及UE的EPC附着，IMS注册，SRVCC切换三部分。
第一部分：EPC附着流程中产生的STN-SR
1.为实现SRVCC功能，先需要在HSS上预定义一个虚假的STN-SR，在此被称为STN-SR(Dummy)（它不会真正用于SRVCC切换，在后续的IMS登记流程中被替换。）
2.当UE发起EPC 附着流程时，UE会在上发的Attach Request信令消息里的MS Network Capability参数的BIT位里标识自己是否支持SRVCC（SRVCC to GERAN/UTRAN capability: SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN supported）
3.MME收到UE的请求后，检查上述的标识，并放置在Update Location Request消息里的UE-SRVCC-Capability（UE-SRVCC-SUPPORTED ）发给HSS。
4.HSS检查上述标识，并将之前预先定义好的STN-SR(Dummy)在Update Location Answer里作为Subscription-Data发送回给MME。
5.MME将通过判断有无收到STN-SR来获悉用户是否开通了SRVCC服务。然后在发回给UE的Attach Accept消息里进行标识（SRVCC Operation Possible:possible），以通知UE网络侧是否允许SRVCC。
第二部分：IMS注册中产生的STN-SR
在EPC附着流程结束后，MME实际上只获得了一个并不会真正用于SRVCC切换的STN-SR（Dummy）。而定义这个虚假STN-SR的主要用意，就是让MME能够获悉用户是否开通了SRVCC业务。下文的IMS注册流程中，让SCC AS能够获悉用户是否开通了SRVCC业务（见图表2中的第2~5步）。
1.首先，为实现SRVCC功能，先需要在ATCF上预定义一个用来标识该ATCF的STN-SR，在这里称为STN-SR(ATCF)。（它将用于SRVCC切换，替换之前的STN-SR（Dummy））。另外，还需要在SCC AS上也预定义一个STN-SR，在这里我们称它为STN-SR(SCC AS)，主要为向下兼容3GPP R9 SRVCC架构。
2.UE在建立IMS缺省承载后，就可发送SIP信令消息到IMS网络。在ATCF（现网与P-CSCF合设）收到UE发上来的REGISTER注册消息后，就会在其中添加STN-SR（ATCF）。如示例：Feature-Caps: +g.3gpp.atcf="<tel:+86137412561>"。这里的tel:+86137412561就是我们的STN-SR（ATCF）。然后ATCF/P-CSCF会将这个添加过SRVCC相关信息的消息继续发送给S-CSCF，完成后续的IMS注册流程。
3.而S-CSCF在完成IMS注册流程后，会根据之前在注册流程中从HSS获得的用户数据IFC（Initial Filter Criteria）中的TRIGGER定义，触发第三方注册流程。将之前IMS注册流程中的REGISTER和200 OK消息封装在新的REGISTER消息中发送给SCC AS，而之前从ATCF获得的STN-SR（ATCF）也包含其中。
4.SCC AS在收到REGISTER消息后，判断其中是否含有STN-SR。如果没有，则表示应使用3GPP R9 SRVCC架构，它就会使用本节点预定义的STN-SR（SCC AS）。如果消息中已有STN-SR，则表示应使用3GPP R10 eSRVCC架构，所以它会使用信令中携带的STN-SR（ATCF）。
5.接下来，SCC AS会通过User Data Request消息（Data-Reference: STN-SR）向HSS查询STN-SR。在这里我们将从HSS获得的STN-SR称为STN-SR（HSS）。(这个值如果是初次开机登记的，是最开始预定义的STN-SR（Dummy）。如果是后续漫游的，则是上一次访问地ATCF分配的STN-SR（ATCF）)
6.同前文提到的MME一样，SCC AS将通过判断有无收到STN-SR来获悉用户是否开通了SRVCC服务。另外，它还将判断，从HSS获得的STN-SR（HSS）与从S-CSCF获得的STN-SR（ATCF）是否相等。如果不相等，SCC AS就会通过Profile Update Request消息（Data-Reference: STN-SR）向HSS发送更新，其中包含STN-SR（ATCF）
7.HSS在收到SCC AS的更新消息后，就会用STN-SR（ATCF）替换之前保存的STN-SR，然后通过Insert Subscriber Data消息将更新后的STN-SR(ATCF)发送到MME。
第三部分：ATCF上STN-SR应用
当SRVCC切换发生时，STN-SR的传递过程（见上图第6-7步）。
1.当MME检测到LTE信号减弱需要切换到CS域以保证通话连续性的情况下，MME通过SRVCC PS to CS Request消息，向关联的eMSC发起SRVCC切换流程。其中携带了更新后的STN-SR（ATCF）和用来关联用户的C-MSISDN。
2.eMSC收到该消息后，将会通过STN-SR（ATCF）进行路由寻址分析，最终找到去往分配该STN-SR的ATCF节点的路由，并将INVITE消息发送至对应的ATCF。其中携带从MME获得的STN-SR（ATCF）和C-MSISDN。（这里可能会通过I-CSCF进行PSI路由寻址到ATCF，也可能直接由DNS解析获得ATCF的IP，具体实现由不同运营商的路由策略决定。）
3.ATCF收到MSC的INVITE消息后，判断其中的STN-SR（Request-URI:tel:+86137412562）是否和本节点预定义的STN-SR相等。如果相等则继续SRVCC流程，根据其中携带C-MSISDN（P-Asserted-Identity: <tel:+8618406630022>）关联到需要执行切换的用户会话，通知ATGW进行相应的承载切换。
4.另外，ATCF还需要根据之前在IMS注册时通过MESSAGE消息从SCC AS获得的ATU-STI地址，向SCC AS发送INVITE消息，以触发相应的计费和LTE PS承载的延时释放。
STN-SR是SRVCC中的关键参数，EPC附着流程和IMS注册流程都会对SRVCC能够成功切换造成影响。而用户数据和节点数据的预定义是否正确也会影响到SRVCC。在故障分析定位时，这些流程和参数都应该仔细的检查。
联系客服
