srvcc

pookie

VoLTE

LTE引入初期只考虑数据业务,随着业务的发展和移动网络的演进,语音业务将逐渐引入,LTE和传统的2G/3G接入都需要具备提供语音业务的能力。为了满足这一要求,需要解决LTE引入后的语音业务如何来提供的问题,包括:语音业务通过何种类型的接入来提供,如何保证语音业务的连续性,以及和其他业务的并发等。为了解决上述问题,目前标准化组织提出了CSFallback,SRVCC和VoLGA三种方案,从不同的需求和思路来解决语音业务的提供问题。

(1)CSFB(CSFallback)"发起语音呼叫,终端切换到3G接入网去实现,实际上使用的是3G接入网,不是LTE网络;CSFB的优点是:不要求部署IMS;对现网的影响较小"缺点是:伴随系统间切换,可能会增加掉话率和时延;需要MSC支持GS接口(目前部分运营商的网络设备没有这个接口)；

(2)SRVCC(SingleRadioVoieeCallContinuity)"部署IMS网络和相应的应用服务器,提供语音业务"SRVCC的优点是:便于将所有业务迁移到IMS上"缺点是:需要部署IMS网络和相应的设备,并且具有支持语音的能力;需要升

级MSC；

(3)VoLGA(VoieeoverLTEviaGenerieAeeess)"是在SAE和CS之间增加网关"语音业务由CS提供"VoLGA的优点是:不需要升级现网设备;不需要部署IMS网络及相关应用服务器"缺点是:需要在EPC和3GCS之间增加一

个网关;已经被3gpp放弃；

VoLTE/SRVCC

VoLTE真正实现端到端全IP语音，主要体现在：其空口IP化，由分组域提供承载，通过IMS进行会话控制；VoLTE难点在于与2G/3G切换流程相对复杂，是核心网电路域与IMS之间的切换，涉及IMS、电路域和LTE核心网之间的互操作，即SRVCC。

VoIMS+SRVCC解决方案是3GPP定义的“单待”LTE终端的最终语音业务解决方案，同时也是实现富通信业务的基础，“单待”终端驻留在LTE网络时，通过EPC作为透明传送的IP通道接入IMS网络提供VoIMS语言业务；当终端移出LTE进入2G、3G覆盖区域，需要EPC与CS域进行协商，并由CS域发起IMS的会话转移流程以及2G/3G无线侧资源的准备，确保会话的连续性。

UE从LTE（语音呼叫承载在GBR上，数据会话在non-GBR上，UE上语音呼叫和数据会话可能并存）切换到2G/3G时，语音按照SRVCC流程切换到CS域，数据会话按照Inter-RAT切换流程切换到PS域。

3GPP TS23.216 R9版本提供的方案如下：

在实际的SRVCC方案实施过程中,为了避免对所有的MSC都进行升级,可以部署独立的SRVCC增强的MSCserver(可以支持SIP和Sv接口)，SRVCC系统架构中,主要网元的功能增强体现如下所示：

1.增强的MSCServer

MSCServer为支持SRVCC而增加的功能如下：

1.1处理MME通过Sv接口发送语音业务的切换准备请求

1.2发起IMS域到CS域的会话切换

        1.3处理CS切换和会话切换流程

2.增强的MME

在SRVCC系统方案中,MME增加的功能如下所示

2.1执行PS承载划分功能,用于区分VoIP承载与非VoIP承载

2.2 Inter-RAT切换过程中实现非VoIP承载的切换

2.3发起SRVCC切换到目标小区

2.4协调PS切换和SRVCC切换执行的同步情况

2.5执行非语音承载挂起和非语音承载恢复

3.增强的HSS

SRVCC系统方案中,Hss除了传统功能外,要需要另外存储一个参数:STN-SR(Session Transfer Number Single-Radio，会话迁移号码)。在UE附着的过程中,HSS会通过插入签约用户数据消息将STN-SR参数传给MME,再转发至MSC。

VoLTE/eSRVCC

eSRVCC（Enhanced Single Radio Voice Call Continuity，增强的单一无线语音呼叫连续性）功能与SRVCC[1] 相比，eSRVCC在保证语音呼叫连续性的同时，尽可能地减小了切换时延，将时延控制在人类所能感知的范围之内，使正在进行的通话不会感觉到有中断的迹象.。

·基于IMS锚定，增加SIP信令锚定点ATCF和媒体锚定点ATGW

·ATCF和ATGW均为逻辑功能实体，可以和P_CSCF、IBCF和MSC Server等功能合设

·ATCF在注册和会话发起阶段均处于SIP信令路径中，并控制ATGW对媒体面进行锚定

·当发生SRVCC切换时，ATCF控制ATGW将媒体面切换到MGW上，其余媒体面保留不变

信令面的切换流程：

业务面的切换流程：

通过拜访地增加锚定节点，缩短媒体更新路径，eSRVCC实现了不超过300ms的切换性能要求。信令面在用户所在本地网络锚定，媒体面切换也在本地进行，不需要通知远端切换媒体面，通常不超过100ms，避免了可能的语言中断，空口切换带来的语音中断无法避免。

SRVCC & eSRVCC 的主要区别

在SRVCC方案中，由于需要在IMS网络中创建新承载，很容易导致切换时长高于300ms，影响终端用户体验。而eSRVCC方案相对于SRVCC方案的增强在于减少了切换时长（切换时长小于300ms），使用户获得更好的通话体验。

eSRVCC在3GPP R10中定义，存在多种解决方案，其中最为主流的方案是在SRVCC网络架构的基础上新增ATCF/ATGW（信令锚定点/媒体锚定点）网元，切换前后的信令与媒体流均要经过ATCF与ATGW；另外，SCC AS功能增强，HSS新增部分透明数据（ATU- STI），其它网元功能不变(MME、eMSC、UE)。

ATCF代替SCC AS进行STN- SR分配，并作为终端切换的本地信令锚点，而SCC AS则同时支持ICS、SRVCC以及eSRVCC多种方案的IMS域远端信令锚定，整个信令锚定流程由ATCF与SCC AS共同完成。

eSRVCC的最大变化是增加了媒体锚点ATGW。当ATGW SDP不变时，则LTE至2G/3G的切换可以不需要更新远端媒体，切换时延减少。当切换后媒体类型（如audio、video）发生变化，或ATGW无法完成Transcoding，以及ATCF发现用户有多路呼叫时，eSRVCC流程才需执行远端媒体更新，即ATCF发起Invite给SCC AS，SCC AS关联到远端用户，并更新远端媒体。

区别：

SRVCC：媒体的切换点是对端网络设备（如对端UE），影响切换时长的主要因素是会话切换后需要在IMS网络中创建新的承载。

eSRVCC：相比于SRVCC，媒体切换点改为更靠近本端的设备。具体方案就是增加ATCF/ATGW功能实体作为媒体锚定点，无论是切换前还是切换后的会话消息都要经过ATCF（Access Transfer Control Function）/ATGW（AccessTransfer Gateway）转发。后续在发生eSRVCC切换时，只需要创建UE与ATGW之间的承载通道，对端设备与ATGW之间的媒体流还是通过原承载通道传输。这样其创建新承载通道的消息交互路径明显短于SRVCC方案，减少了切换时长。

SRVCC的信令流程

当UE附着在LTE网络时,发起呼叫一般采用IMS语音呼叫,并且要将该呼叫锚定到IMS域的业务连续性服务器上(SCC AS)。随着用户的移动，UE可能移除LTE网络的覆盖区域,为了保证语音呼叫的连续性,就需要执行SRVCC流程,将锚定在IMS域中SCCAS上的IMS语音平滑切换至GERAN用TRAN的CS网络SRVCC切换的高层概念流程如下图所示：

1:E-UTRAN执行测量流程

2:E-UTRAN(eNodeB)决定需要执行切换处理,将该UE切换到2G/3G网络下面

3:MME根据E-UTRAN的切换指示,向2G/3G网络下的MSCServer发起SRVCC切换

4:如果当前存在承载IMS语音之外的普通分组业务的承载,则MME向2G/3G网络中的SGSN发起PS切换流程

5:MSCServer收到MME发送的SRVCC切换指示后,执行标准的CS切换准备流程,要求目标的2G/3G网络的基站为即将要切换的CS语音准备资源

6:MSCServer还需要向IMS网络发送域切换指示,要求IMS域的SCCAS将IMS信令和语音流从E-UTRAN网络切换到2G/3G网络中,即执行IMS服务连续性流程

7:MSCServer执行完CS切换准备流程后,向MME发送CS切换响应

8:MME收到MSCServer和SGSN发送的切换相应消息后,指示E-UTRAN网络发起切换流程

9:E-UTRAN向UE发送切换命令,UE根据该切换命令执行切换流程,完成到2G/3G网络的切换,从而完成SRVCC的切换处理

下图的具体流程为E-UTRAN到UTRAN的PS和CS的同时切换，如下图：

整个切换流程大体可以分为切换判决、切换发起、切换准备、切换执行等几个步骤。

1.基于UE的测量报告,源E-UTRAN决定触发至GERAN/UTRAN的切换；

2.源E-UTRAN发送切换请求消息至源MME；

3.基于语音承载相关的QCI(QoSClassIdentifier),源MME将语音承载从其他PS承载中分离出来,并执行一下步骤

3.1源MME通过向MSCServer发送前转重定位请求消息(STN-SR、MSISDN、源至目标的透明容器、MM上下文)来发起语音承载的PS切换流程；

3.2MSCServer通过向目标MSC发送切换请求准备消息来实现PS切换请求与CS域Inter-MSC切换请求的互操作。CS域安全密钥可以通过包含在MM上下文中的E-UTRAN/EPS域密钥推导得出；

3.3目标MS通过向目标RNS发送重定位请求消息,为CS重定位请求资源分配。

4.该步骤与第三步并行执行。源MME发起剩余非语音PS承载的重定位,并执行以下步骤：

4.1源MME向目标SGSN发送前转重定位请求消息(源至目标的透明容器、MM上下文),该消息仅仅包含非语音部分的信息。

4.2目标SGSN通过向目标RNS发送重定位请求消息,为PS重定位请求分配资源。

5.目标RNS关联CS重定位请求与PS重定位请求,并分配资源。

5.1目标RNS通过向目标SGSN发送重定位请求确认消息来确认PS重定位已准备就绪"

5.2目标SGSN向MME发送重定位请求响应消息。

6.与第五步并行的执行以下步骤。

6.1目标RNS通过向目标MSC发送重定位请求确认消息来确认CS重定位已经准备就绪。

6.2目标MSC向MSCServer返回一条准备切换响应消息。

6.3建立目标MSC与MSCServer/MGW之间的电路域连接,可以使用ISUPIAM和ACM消息。

7.通过使用STN-SR，MSCServer可以触发会话迁移流程,通过发送ISUPIAM(STN-SR)消息至IMS网络,在会话迁移过程中执行标准的IMS业务连续性流程。

8.MSCServer发送前转重定位响应消息至源MME。

9.源MME同步两个准备的重定位,并发送切换命令消息至源E-UTRAN。

10.E-UTRAN发送切换命令消息至UE。

11.目标RNS进行切换检测。

12.CS重定位完成,并执行以下步骤。

12.1目标RNS发送重定位完成消息至目标MSC。

12.2目标MSC发送一条SES(切换完成)消息至MSCServer。

12.3MSC与MsCserver关联的Mow之间的电路连接建立完成。

12.4MSCServer发送一条前转重定位完成消息至MME,随后源MME发送前转重定位完成确认消息来响应MSCServer。

12.5如果有必要,MSCServer会向HSS/HLR发起位置更新的MAP消息。

13.与第十二步并行的执行，PS重定位完成,并执行以下的步骤。

13.1目标RNS发送重定位完成消息至目标SGSN"

13.2目标SGSN发送一条前转重定位完成消息至源MME,随后源MME发送前转重定位完成确认消息来应答目标SGSN。

13.3目标SGSN更新S-GW与PDN-GW上的承载

SRVCC & eSRVCC E-UTRAN的工作

l NAS层承载功能要求

n 支持多PDN连接，其中IMS专用APN（用户不可见）单独建立PDN连接

n 支持SRVCC能力上报、获知LTE接入网是否支持VoLTE

l L2/L3功能要求

n 语音承载基本功能：QCI=1的Qos保证

n 语音承载无线优化功能：IP头压缩功能

n 异系统测量及控制、SRVCC切换

l L1功能要求

n 半持续调度SPS、TTI Bundling

l RRM功能要求

n 语音承载算法优化功能：针对语音业务的RRM算法优化

介于SRVCC & eSRVCC的区别主要在核心网侧，在eNodeB侧的看来是透明的，根据目前了解到的知识，总结如下几个工作，主要是L2/L3的功能要求：

1. SRVCC Operation Possible：（both UE and target MME are SRVCC Capable）

SRVCC Operation Possible 在INITIAL CONTEXT SETUP REQUEST 中获得，而该值是否在HO required msg中携带（当达到门限后，是SRVCC到Inter-RAT 还是 Handover到邻区），有如下情况：【TS23.216 A.2】

1）收到SRVCC Operation Possible，UE存在QCI=1的承载，目标小区支持VoIP，则在切换消息中不携带；

2）收到SRVCC Operation Possible，UE存在QCI=1的承载，目标小区不支持VoIP，则携带；

3）收到SRVCC Operation Possible，UE不存在QCI=1的承载，不携带；

如果未收到SRVCC Operation Possible，则在HO required消息中将不携带该指示：

1）如果UE存在QCI=1的承载，那么不支持VoIP的小区就不在邻区列表中；

2）如果UE不存在QCI=1的承载，那么不支持VoIP的小区就可能在邻区列表中；

2. SRVCC HO Indication：（CS only、 PS and CS） --HO required msg

a) 解析UE DTM HO Cap；

b) 获取目标系统的DTM HO Cap；

3. Inter-RAT 的切换流程：B1/B2的测量及切换的支持；

SRVCC

1.支持基于IMS的由LTE承载的IP话音，采用SRVCC方式切换至GSM承载保证话音连续

a) 支持SRVCC的VoLTE UE attach LTE小区，做VoIP业务，正常；

b) UE远离LTE小区，达到异系统切换门限，上报测试报告；

c) E-UTRAN判断执行SRVCC切换，发起HO请求，包含SRVCC indicator；

d) E-UTRAN收到HO Cmd，并下发切换至GSM；

e) UE成功切换，之间业务中断时间不超过300ms[注]，业务保持畅通。

2.支持基于IMS的由LTE承载的IP话音，采用SRVCC方式切换至TD-SCDMA承载保证话音连续

a)        支持SRVCC的VoLTE UE attach LTE小区，做VoIP业务，正常；

b)         UE远离LTE小区，达到异系统切换门限，上报测试报告；

c)         E-UTRAN判断执行SRVCC切换，发起HO请求，包含SRVCC indicator；

d)         E-UTRAN收到HO Cmd，并下发切换至UTRAN；

e)        UE成功切换，之间业务中断时间不超过300ms，业务保持畅通。

3.SRVCC功能开启后，在触发其它互操作流程前，支持先确认终端是否存在QCI=1的VoLTE业务，后续处理需优先保障语音业务体验，避免后续处理影响语音业务连续性；

a) 支持SRVCC的VoLTE UE attach LTE 小区，做VoIP业务 & PS业务（ping）；

b) UE远离LTE小区，达到异系统切换门限，上报测量报告；

c) E-UTRAN判断有QCI=1的语音业务，发起SRVCC切换，包含SRVCC HO indicator（CS only），PS由MME挂起；

d) E-UTRAN收到HO CMD，并下发切换至UTRAN/GSM；

e) UE成功切换，业务畅通；

f) VoIP结束，回到E-TURAN，发起TAU并恢复之前挂起的PS业务；

4.支持基于覆盖、负载、语音质量（例如时延、时延抖动、丢包率）触发的SRVCC

a) 支持SRVCC的VoLTE UE attach LTE小区，做VoIP业务；

b) E-UTRAN侧，通过分析UE的测量报告、VoIP的包延时、抖动等情况，发起SRVCC的切换；（具体根据什么指标检测负载、语音质量待研究）；

c) E-UTRAN收到HO CMD，并下发切换到UTRAN/GSM；

d) UE成功切换，业务中断时间不超过300ms，业务保持；