[转载]VoLTE技术中的会话持续性

        对于eSRVCC用户的注册，SCC AS在注册成功后，向终端发送MESSAGE，MESSAGE的消息体中含有ATU-STI与C-MSISDN(从HSS下载得到，属于签约放号数据)。ATU-STI由SCC AS自己产生，用来识别呼入请求是否是eSRVCC用户发来的切换请求。

 

      ATCF在注册消息的Feature-Caps头部携带了多个信息：

      1, +g.3gpp.atcf填写STN-SR，用于向SCC AS、HSS、MSC Server更新用户的SRVCC地址信息。

      2，+g.3gpp.atcf-mgmt= "<sip:actf.visited2.net>"用于SCC AS向ATCF发送message消息时的request URI。

 

        STN-SR实际上分两种：STN-SR、vSTN-SR。见SRVCC方案。    

 

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

                Table A.3.3-1: SIP REGISTER request (UE to P-CSCF)

REGISTER sip:home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8

Max-Forwards: 70

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

From: <sip:[e-mail]>;tag=2hiue

To: <sip:[e-mail]>

Contact: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>;+sip.instance="<urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn:urn-7%3gpp-service.ims.icsi.mmtel"

Call-ID: E05133BD26DD

Authorization: Digest username="[e-mail]", realm="registrar.home1.net", nonce="", uri="sip:home1.net", response=""

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 1 REGISTER

Supported: path, gruu

Content-Length: 0

 

                Table A.3.3-3: SIP REGISTER request (ATCF towards S-CSCF)

REGISTER sip:home1.net SIP/2.0

Feature-Caps: *;+g.3gpp.atcf="<tel:[phone]>"; +g.3gpp.atcf-mgmt= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:[e-mail]>";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting

Path:     <sip:[e-mail]>,<sip:[e-mail]:5070;ob>

Route: <sip:icscf.home1.net;lr>

P-Visited-Network-ID:

P-Charging-Vector:

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas5889; SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee

Max-Forwards: 68

P-Access-Network-Info:

 

 

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

 

 

        所有IMS呼叫都锚定到ATCF，ATCF需要知道用户是否支持SRVCC功能(这样才能控制SRVCC用户的呼叫媒体锚定到ATGW，并才能在呼叫、切换时进行特定处理)，

        ATCF在注册结束后，会从SCC-AS得到一个message消息：携带C-MSISDN、ATU-STI及用户是否支持SRVCC功能标记（即切换到CS域的功能）

    　SCC-AS如何知道用户是否支持SRVCC:UE在LTE中附着时，会指示自己是否支持SRVCC，MME将这种标记存入HSS。SCC-AS在用户注册时会从HSS下载用户数据，其中含SRVCC能力。

 

        所有IMS用户的IMS注册都被SBC发给Visited域的ATCF，ATCF把自己加到Path上，发给S-CSCF。

       后来这些用户（含SRVCC用户与非SRVCC，或分为：固定用户、Volte用户）的呼叫都经过了ATCF。ATCF根据在注册后得到的用户SRVCC能力来 控制SRVCC用户的呼叫媒体锚定到ATGW（这是呼叫流程中最重要的工作），而非SRVCC用户则不需要锚定媒体。

 

   

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

   

    对于接受注册和VoLTE呼叫的ATCF来说，需要让MSC把切换请求发给自己。这样才是完全的“锚定”功能。

     MME控制切换到CS域、PS域的方法与SRVCC一样。

     eMSC在切换时，发invite给ATCF（其中带STN-SR，C-MSISDN)给ATCF。由于STN-SR是ATCF自己分配的，它会知道这是一个切换请求，并根据C-MSISDN关联到IMS用户和现有呼叫。

    对eMSC来说，这个操作与SRVCC方案中一样。 区别只是：SRVCC中，呼叫是完全锚定到SCC-AS，由eMSC直接把切换invite发给SCC-AS。而eSRVCC中锚定由ATCF与SCC-AS共同完成，eMSC必须把切换invite发给ATCF。

  

      STN-SR是给MSC在切换请求时使用的，由ATCF在注册时产生。 一般是标识ATCF的全局PUI，或称为PSI，因为是给MSC用的，一般是Tel URI格式。 

     当原IMS呼叫有几路时，ATCF收到MSC发来的呼叫中，必须选择关联其中一路：先选择Active的呼叫，再选择。。。这之中有个逻辑判断（由ATCF自己做）

     而ATCF发invite(被叫是ATU-STI，主叫是用户PUI)给SCC-AS。 SCC-AS返回SSI给ATCF和MSC。（SSI用于 mid-call 切换 中关联呼叫所用）

 

     ATU-STI是给ATCF在切换请求时使用的，由SCC AS在注册时产生。

     SCC AS在注册时产生ATU-STI。它用Message通知ATCF:UE的C-MSISDN，以及分配的ATU-STI，还有UE的SRVCC 能力

     ATCF使用C-MSISDN来关联会话(MSC发来切换请求时)，使用ATU-STI替换与SCC AS之间的信令路径(在发起切换呼叫到SCC-AS时）。原信令leg会被ATCF或SCC-AS释放。

      C-MSISDN是很重要的，因为IMS用户PUI与CS域号码可能是不一样的。ATCF收到MSC发来切换请求（带C-MSISDN，它表示了主叫的身份）时，再关联到现存的几个IMS呼叫中的一个。  

 

      ATU-STI是全局PSI。像STN-SR一样，都是一个全局PSI，所以要关联到某个用户的某一路旧呼叫的话，要根据新呼叫中带的PAI(用于关联到用户）、Target-Dialog（像replace一样，含有旧呼叫的dialog ID)

     用户原来有多路呼叫时，决定替换哪一路由ATCF决定，其原呼叫的dialog id 置入Target-Dialog参数中。

      当切换请求invite被eMSC发给ATCF，ATCF置被叫号码为ATU-STI（主叫号码为用户PUI），且携带Target-Dialog参数(其中含原LTE呼叫的SIP 会话ID），这个invite发给SCC AS。

      SCC AS会执行替换呼叫的操作(不切换远端媒体)与释放原呼叫的local leg：SCC AS使用Target-Dialog参数来寻找到原呼叫的数据区。在invite的200 响应中，SCC AS携带Feature-Caps：*；+g.3gpp.srvcc

      如切换请求(根据被叫是否是ATU-STI决定）的invite中没有携带Target-Dialog参数时（而不完全靠被叫是ATI或STN-SR来判断是否执行SRVCC），SCC AS执行SRVCC方案，即从用户的多路选叫中选中一路来update remote end.（SRVCC方案中，决定替换哪一路的决策由SCC AS来做）。

   

       而对SCC-AS来说，在收到ATCF发来用于切换的invite时，根据Target-dialog中的dialog id来关联到用户现存的4路呼叫中的一路。在这个呼叫关联完成后（呼叫关联的工作包括：向主叫用户即ATCF发送200OK，即完成新呼叫的创建，另外还要释放掉旧呼叫的leg。  因为是B2BUA网元，所以不用通知到远端IMS用户，除非需要更新远端媒体)。

      SCC-AS还要从剩下3路呼叫中选择一路呼叫来发起refer给ATCF->MSC，命令UE发起另一路呼叫的创建。依次选择几路呼叫的顺序也有一个逻辑判断（由SCC-AS自己做）

 

    LTE侧的IMS呼叫的振铃态切换的判断：当用户invite的contact中含有g.3gpp.srvcc-alerting feature tag时，它表示终端与ATCF 是否支持振铃态eSRVCC。SCC-AS可以根据这来判断是否做振铃态切换。

 

      在振铃态或媒体为inactive状态（即多路呼叫）的会话切换中,给ATCF发info消息,其包含Info-Package:g.3gpp.state-and-event-info和Content-Type:application/vnd.3gpp.state-and-event-info+xmls,及相关的XML描述。

       在呼叫消息中支持对Contact:<sip:msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn:urn-7%3gpp-service.ims.icsi.mmtel"、Target-Dialog、Recv-Info、P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mmtel信息的处理,用于切换与判断是否支持振铃态和mid-call的切换。在响应消息中携带feature-caps头部。

     这是为了作振铃态切换。

 

      所有的切换请求、响应（18x,200)中都会带feature-caps:srvcc。用于标识eSRVCC切换呼叫。eSRVCC流程中出现了各种feature-code，携带各种关键参数。

 

 

     ATCF没有锚定媒体

 

 

其它技术点

 

IMS-HSS新增数据项

HSS的Sh接口透明数据中（29.328-b50)，有

MSISDN ：可能包括几个号码，即C-MSISDN,

Extended MSISDN 

Additional MSISDN (A-MSISDN) 

Private Identity 

T-ADS Information

            -    IMS-VOICE-OVER-PS-NOT-SUPPORTED (0)

            -    IMS-VOICE-OVER-PS-SUPPORTED (1)

            -    IMS-VOICE-OVER-PS-SUPPORT-UNKNOWN (2)

STN-SR

UE SRVCC Capability

            -    UE-SRVCC-CAPABILITY-NOT-SUPPORTED (0)

            -    UE-SRVCC-CAPABILITY-SUPPORTED (1)

CSRN

        在向IMS-HSS请求"MSISDN"时，需要在"User Identity"中填写PUI，在"User-Name"中填写PVI(从SIP注册消息的Authorization中获取) .

 

 

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

       所有VoLTE用户中并非所有用户都是eSRVCC用户。或者部分用户是SRVCC用户、另一部分用户是eSRVCC用户。因为eSRVCC用户的语音质量更好，可能视为高端用户。这里的想法是：如何区分SRVCC用户、eSRVCC用户或非SRVCC用户。

       eSRVCC功能要求：eSRVCC用户的媒体通过ATGW锚定，那么这些用户的注册、呼叫、切换信令是必须经过ATCF的。但其它 非eSRCC用户 是不需要让呼叫经过ATCF，仍经过P-CSCF->I-CSCF->S-CSCF即可。

      所有用户注册时（CS域 ICS用户，可能通过eMSC注册），注册信息必须经过P-CSCF->ATCF->I-CSCF。因为注册时，这些网元并不知道用户是否是合格的eSRVCC用户，甚至不知道是否是IMS用户。P-CSCF，ATCF会在用户注册时，将自己加到path路径上。  这一点是没有异议的。

 

      有一种控制呼叫是否锚定到ATCF的方法是由S-CSCF在注册时判断用户是否支持SRVCC功能（   S-CSCF在用户注册时，可以从Cx接口的签约数据中得到用户是否有SRVCC能力（目前的Cx标准 29228-b50 中没有这个信息））

      如支持，S-CSCF修改path头(使其中不含ATCF，用于被叫侧S-CSCF找下一跳）与产生service-route头(其中不需要含ATCF地址）（这里也要求S-CSCF能知道 path头中哪个URI是表示ATCF的，ATCF在注册消息的Feature-Caps中会带上自己的atc-path，另一种办法是让S-CSCF上配置ATCF域名），Service-route头在注册响应里原路返回发给P-CSCF,ATCF 等，UE把这个头反向复制到到 新产生呼叫的route头中。

 

      P-CSCF在收到呼叫消息时，删除信令中的service-route头（终端发来的，不可靠），按本身存储的service-route头再复制一份route头（当然会从中删除自己），这个呼叫消息会发给S-CSCF（不可能发给ATCF）

      如用户没有SRVCC能力，通过这种方法就可以控制呼叫消息不经过ATCF。

     这样：只有SRVCC的呼叫会经过ATCF。而普通IMS用户呼叫不会经过ATCF。

 

缓存8秒的过程   

       虽然锚定到ATGW的媒体端口、IP、编解码在切换前后没有变化，但信令路径发生了改变。所以ATCF需要发切换请求给SCC AS(因为原呼叫路径会自动释放)。

       原IMS呼叫路径包括了UE的IMS应用、SBC、P-CSCF、SCC-AS 都会因为session timer功能或刷新注册时间到却没收到刷新注册消息，而释放呼叫。（SCC-AS在释放呼叫或收到 ATCF侧发来的bye消息时，只释放这一边的leg ，远端leg 要保留）

      原IMS路径上的leg 释放，与 MSC发呼叫给ATCF ：这两个操作的时间顺序不确定。为了防止用户在session timer即将到期时发起切换，标准要求SCC-AS在收到释放近端leg的请求时，保留leg 8秒钟。

       SCC-AS收到ATCF发来的新invite时，如原leg还在，SCC-AS会释放它。

 

      在手机信号变弱时，或原呼叫的session timer到期时，UE或CSCF会发bye，但此时对于SRVCC用户会发起切换。

      所以：要求ATCF、CSCF、SCC-AS 对于SRVCC用户的呼叫，在释放消息到时会缓存8秒。 或只由SCC-AS来做，因为CSCF上没有用户信息，当CSCF主动发bye给SCC AS时，SCC AS缓存8秒即可。

    　CSCF的sesison time到期时，向上，向下都发bye。向下发给ATCF，ATCF也要缓存8秒，以防止这段时间内切换消息从MSC发来。

      如果CSCF不做这种缓存的话，就要求 SCC AS与ATCF 均要缓存8秒（如SCC有缓存，而ATCF不缓存的话，ATCF会在收到CSCF的bye时释放呼叫，后续当MSC发来切换请求时，就无法完成eSRVCC切换流程）。

 

eSRVCC是否兼容SRVCC

      eSRVCC的流程变化关键点体现在ATCF、SCC AS。

      如果要求网络中同时存在eSRVCC、SRVCC两种用户，比如对于高端用户提供eSRVCC流程，而eSRVCC流程要求ATCF的信令与媒体锚定，eSRVCC用户容量受ATCF与ATGW配置所限。

　　ATCF、SCC AS通过注册成功可以鉴定用户是否是IMS用户，那么如何识别三种用户（普通IMS用户、SRVCC用户、eSRVCC用户)呢？

    

      ATCF在注册时不区分是否SRVCC或IMS用户，由SCC AS从HSS得到用户支持C-MSISDN与SRVCC能力的参数，则证明用户支持SRVCC能力并经过SRVCC业务签约，SRVCC能力会在Message里下发给ATCF。

      这种方案支持eSRVCC用户漫游到外地:1,visited网有ATCF，则走eSRVCC流程。  2，visited网没有ATCF，由P-CSCF接入home域IMS，SCC AS走SRVCC流程（SCC AS通过注册、呼叫消息中是否带feature-code来判断是否有ATCF接入）

       上述方案可以鉴别IMS用户与SRVCC用户(也含eSRVCC用户）。

 

      如何鉴别SRVCC用户与eSRVCC用户呢?

      两种看法：

1，ATCF部署后，网络中只有eSRVCC用户，没有SRVCC用户（因为eSRVCC与SRVCC对终端的要求是一样的，只是网络侧能力不同）。则SCC AS只要发现用户注册、呼叫带了feature-code，则走eSRVCC流程。

2，ATCF部署后，网络中eSRVCC用户与SRVCC用户并存。SCC AS在HSS的用户透明数据中用特定业务属性表示用户是否是eSRVCC用户。

 

 

eSRVCC的缺点

    eSRVCC也有人分析出不足之处：

    1，不能适应高速移动场景：当在高速列车上进行切换时，时延还是太长。

    2，复杂性：SCC-AS新增功能，引入新的ATCF/ATGW网元。尤其是mid-call feature业务的复杂性。