eSRVCC中STN-SR的由来与使用

eSRVCC中STN-SR的由来与使用SRVCC是3GPP提出的一种VoLTE语音业务连续性方案，主要是为解决当单射频UE在LTE网络和2G/3GCS网络之间移动时，如何保证语音呼叫连续性的问题，即保证单射频UE在VoLTE语音和CS域语音之间的平滑切换。一、STN-SR产生背景LTE开网初期网络覆盖不足，用户在使用VOLTE语音通话过程中，随着用户的移动，离开LTE覆盖范围后，正在进行的语音业务面临掉话问题。为解决这一问题3GPP在R9版本引入了SRVCC方案。在R9SRVCC方案中，切换的控制锚点位于归属地SCCAS(ServiceCentralizationandContinuityApplicationServer)上，很容易导致切换时长超过300ms，影响终端用户体验。而3GPP在R10版本推出了eSRVCC方案，将切换锚点前移至访问地的ATCF（AccessTransferControlFunction）/ATGW（AccessTransferGateway）上。这样当发生eSRVCC切换时，只需要创建UE与ATGW之间的承载通道，对端设备与ATGW之间的媒体流还是通过原承载通道传输。这样就大大减少切换时长，使用户获得更好的通话体验。图表1.eSRVCC切换前后信令及承载通道在eSRVCC中一个很关键的参数就是STN-SR(SessionTransferNumber-SingleRadio)。它用来在发生eSRVCC切换时，帮助MSC正确的找到对应的ATCF，完成切换。二、STN-SR格式STN-SR是一个E.164格式的路由号码，用来标识处理SRVCC切换的IMS节点。在eSRVCC里，它用来标识用户在IMS注册登记时关联的ATCF节点，当发生eSRVCC切换时MSC将使用从EPC域的MME处获得的STN-SR号码，来向IMS域的ATCF寻址，并发起SRVCC切换请求，请求将媒体承载路径从LTEPS切换到CS(这种支持与MME间Sv接口的MSC，也被称为eMSC（EnhancedMSC）。图表2.STN-SR生成及应用网元三、STN-SR生成使用三步曲STN-SR生成和使用主要涉及UE的EPC附着，IMS注册，SRVCC切换三部分。第一部分：EPC附着流程中产生的STN-SR1.为实现SRVCC功能，先需要在HSS上预定义一个虚假的STN-SR，在此被称为STN-SR(Dummy)（它不会真正用于SRVCC切换，在后续的IMS登记流程中被替换。）2.当UE发起EPC附着流程时，UE会在上发的AttachRequest信令消息里的MSNetworkCapability参数的BIT位里标识自己是否支持SRVCC（SRVCCtoGERAN/UTRANcapability:SRVCCfromUTRANHSPAorE-UTRANtoGERAN/UTRANsupported）3.MME收到UE的请求后，检查上述的标识，并放置在UpdateLocationRequest消息里的UE-SRVCC-Capability（UE-SRVCC-SUPPORTED）发给HSS。4.HSS检查上述标识，并将之前预先定义好的STN-SR(Dummy)在UpdateLocationAnswer里作为Subscription-Data发送回给MME。5.MME将通过判断有无收到STN-SR来获悉用户是否开通了SRVCC服务。然后在发回给UE的AttachAccept消息里进行标识（SRVCCOperationPossible），以通知UE网络侧是否允许SRVCC。第二部分：IMS注册中产生的STN-SR在EPC附着流程结束后，MME实际上只获得了一个并不会真正用于SRVCC切换的STN-SR（Dummy）。而定义这个虚假STN-SR的主要用意，就是让MME能够获悉用户是否开通了SRVCC业务。下文的IMS注册流程中，让SCCAS能够获悉用户是否开通了SRVCC业务（见图表2中的第2~5步）。1.首先，为实现SRVCC功能，先需要在ATCF上预定义一个用来标识该ATCF的STN-SR，在这里称为STN-SR(ATCF)。（它将用于SRVCC切换，替换之前的STN-SR（Dummy））。另外，还需要在SCCAS上也预定义一个STN-SR，在这里我们称它为STN-SR(SCCAS)，主要为向下兼容3GPPR9SRVCC架构。2.UE在建立IMS缺省承载后，就可发送SIP信令消息到IMS网络。在ATCF（现网与P-CSCF合设）收到UE发上来的REGISTER注册消息后，就会在其中添加STN-SR（ATCF）。如示例：Feature-Caps:+g.3gpp.atcf=tel:[phone]。这里的tel:[phone]就是我们的STN-SR（ATCF）。然后ATCF/P-CSCF会将这个添加过SRVCC相关信息的消息继续发送给S-CSCF，完成后续的IMS注册流程。3.而S-CSCF在完成IMS注册流程后，会根据之前在注册流程中从HSS获得的用户数据IFC（InitialFilterCriteria）中的TRIGGER定义，触发第三方注册流程。将之前IMS注册流程中的REGISTER和200OK消息封装在新的REGISTER消息中发送给SCCAS，而之前从ATCF获得的STN-SR（ATCF）也包含其中。4.SCCAS在收到REGISTER消息后，判断其中是否含有STN-SR。如果没有，则表示应使用3GPPR9SRVCC架构，它就会使用本节点预定义的STN-SR（SCCAS）。如果消息中已有STN-SR，则表示应使用3GPPR10eSRVCC架构，所以它会使用信令中携带的STN-SR（ATCF）。5.接下来，SCCAS会通过UserDataRequest消息（Data-Reference:STN-SR）向HSS查询STN-SR。在这里我们将从HSS获得的STN-SR称为STN-SR（HSS）。(这个值如果是初次开机登记的，是最开始预定义的STN-SR（Dummy）。如果是后续漫游的，则是上一次访问地ATCF分配的STN-SR（ATCF）)6.同前文提到的MME一样，SCCAS将通过判断有无收到STN-SR来获悉用户是否开通了SRVCC服务。另外，它还将判断，从HSS获得的STN-SR（HSS）与从S-CSCF获得的STN-SR（ATCF）是否相等。如果不相等，SCCAS就会通过ProfileUpdateRequest消息（Data-Reference:STN-SR）向HSS发送更新，其中包含STN-SR（ATCF）7.HSS在收到SCCAS的更新消息后，就会用STN-SR（ATCF）替换之前保存的STN-SR，然后通过InsertSubscriberData消息将更新后的STN-SR(ATCF)发送到MME。第三部分：ATCF上STN-SR应用当SRVCC切换发生时，STN-SR的传递过程（见上图第6-7步）。1.当MME检测到LTE信号减弱需要切换到CS域以保证通话连续性的情况下，MME通过SRVCCPStoCSRequest消息，向关联的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:[phone]）是否和本节点预定义的STN-SR相等。如果相等则继续SRVCC流程，根据其中携带C-MSISDN（P-Asserted-Identity:tel:[phone]）关联到需要执行切换的用户会话，通知ATGW进行相应的承载切换。4.另外，ATCF还需要根据之前在IMS注册时通过MESSAGE消息从SCCAS获得的ATU-STI地址，向SCCAS发送INVITE消息，以触发相应的计费和LTEPS承载的延时释放。STN-SR是SRVCC中的关键参数，EPC附着流程和IMS注册流程都会对SRVCC能够成功切换造成影响。而用户数据和节点数据的预定义是否正确也会影响到SRVCC。在故障分析定位时，这些流程和参数都应该仔细的检查。