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
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 的信令传输时间。

 

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

      eSRVCC可视为SRVCC的升级版本(实际上 SRVCC方案与eSRVCC方案 可以在一个运营商网络中共存 )。
   与SRVCC相比,新增ATCF/ATGW网元,SCC-AS功能有增强,HSS透明数据有新增。其它网元功能不变(比如MME、eMSC、UE)
 
信令面、媒体面在切换前后的路径

    切换的信令面变化,参见:

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

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

    媒体面的切换路径参见:

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

   切换前后的媒体均经过了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业务流程
一、用户注册流程:STN-SR,ATU-STI,C-MSISDN
     用户在LTE侧发起注册,呼叫在LTE承载上,经过PGW发到互联网上IMS域:P-CSCF/A-SBC->ATCF->S-CSCF->SCC AS。
    VoLTE技术中的会话持续性-eSRVCC
     注册时,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) 。
  
       对于SCC-AS来说,由于同时作为ICS、SRVCC、eSRVCC方案的网元,当收到呼叫时,需要识别当前所承担的网元角色。
       在SCC-AS收到S-CSCF发来的第三方注册请求消息中,携带Feature-Caps头部(由ATCF插入),如SCC-AS发现Feature-Caps中存在+g.3gpp.atcf参数,则认为是eSRVCC用户的注册。
      
       对于eSRVCC用户的注册,SCC AS会把+g.3gpp.atcf信息更新到IMS HSS,并从IMS HSS下载到特定的用户数据(非透明数据,见“IMS-HSS新增数据项”一节)。
            对于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:[email protected]>;tag=2hiue
To: <sip:[email protected]>
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="[email protected]", 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:+1-237-888-9999>"; +g.3gpp.atcf-mgmt= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:[email protected]>";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting
Path:        <sip:[email protected]>,<sip:[email protected]: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
VoLTE技术中的会话持续性-eSRVCC
 
VoLTE技术中的会话持续性-eSRVCC
 
                所有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技术中的会话持续性-eSRVCC 
    对于接受注册和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,携带各种关键参数。
 
 
VoLTE技术中的会话持续性-eSRVCC
        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业务的复杂性。
 
 


通过 为知笔记 发布


你可能感兴趣的:(VoLTE技术中的会话持续性-eSRVCC)