-
LTE
的语音解决方案
目前有
CSFB
、单卡双待机、
VoLTE/SRVCC
等多种
LTE
手机语音解决方案。
CSFB
和双待机方案，由
2/3G
电路域提供语音；
VoLTE
方案，由
LTE
分组域提供语音，并通过
SRVCC
功能保证与
2/3G
话音平滑切换。
VoLTE/SRVCC
和
CSFB
对网络有升级改造要求。
双待机为终端实现方案，其本身对网络无升级要求，为满足数据业务互操作，需对
2G<
/p>
进行
相关升级，但对终端定制化要求较高。
▊
Volte
与
< br>RCS
的关系
RCS
（
Rich
Communication Suite
）：电信运营商提供整套基于通讯录的呈现、
即时通信、
群组聊天、
文件传送等在线通信应用，
帮助运营商占据无线社匙市场主动地位，
具有良好的
互操作能力。
RCS-e
（
Rich
Communication Suite-enhanced
）：实际为欧洲运营商联
盟为了尽快部署
RCS
而推出的简化版本，语音仍基于电路域。
VoLTE
语音、
LTE
高清可视电话、消息、甚至
eSRVCC
等均是独立的业务能力，而
RCS
是
一个包含了多种能力的产品套件形态。
能力可以不基于
RCS
产品来提供，但结合
RCS
实现效果可能会更好。<
/p>
▊
SRVC
C
与
eSRVCC
3GPP
在
R8
阶段引入
SRVCC/eSRVCC
方案，在
SRVCC
方案中，由于需要在
IMS
网络中创
建新承载，很容易导致切换时长高于
300ms
，影响终端用户体验。而
eSRV
CC
方案相对于
SRVCC
方案的增强
在于减少了切换时长（切换时长小于
300ms
），使用户获得
更好的通话
体验。
SRVCC
：媒体的切换点是对端网络设备（如对端
U
E
），影响切换时长的主要因素是会话切
换后需要在
IMS
网络中创建新的承载。
eSRVCC
：相比于
SRVCC
，媒体切换点改为更靠近本端的设备。具体方案就是增加
ATCF/ATGW
功能实体作为媒体锚定点，
无论是切换前还是切换后的会话消息都要经过
ATCF
（
Access Transfer Control Function
）
/ATGW
（
AccessTra
nsfer Gateway
）转发。后续在发
生
eSRVCC
切换时，只需要创建
UE
与
ATGW
之间的承载通道，对端设备与
ATGW
之间的
媒体流还是通过原承载通道传输。
这样其创建新承载通道的消息交互路径明显短于
SRVCC
方案
，减少了切换时长。
SRVCC
基本架构
在
LTE
覆
盖范围内通过
IMS
提供
VoIP
语音，
IMS
提供呼叫控制及后续的切换控
制。
在用户通话过程中移出
LTE
覆盖范围时，
IMS
< br>作为控制点与
CS
域交互，将原有通话切换到
CS
域，保证语音业务连续性。
SRVCC
关键技术点：
1.
在
MSC Server
和
MME
之间定义
S
v
接口，提供异构网络间接入层切换控制；
2.
通过设臵
IWF
互通网元，终结
Sv
接口，避免对原有电路域设备的改
造；
3. IMS
网络作为会话锚定
点，统一进行会话层切换，保证会话跨网切换的连续性。
SRVCC
流程及切换性能
1.
发起
VoLTE
呼叫：
SRVCC
终端发起
向另一
IMS
终端的语音呼叫；
2.
呼叫建立：呼叫成功，媒体连接建立，双方进行通话；
3.
发起
SRVCC
切换：用户离开
LTE
覆盖，发生
SRVCC
切换
,EPC
网络通知
SRVCC MSC
准
备切换，
MSC
完成电路域资源预留；
4.
终端切换：
MSC
通过
LTE
网络通知终端切换到
2G/TD
；
5.
远端媒体更新：
SRVCC MSC
发
起远端媒体更新，通知远端
IMS
终端通过
SRVCC MSC
接
收和发送语音；
6.
媒体切换：进端
IMS
终端将媒体连接切换至
SRVCC
MSC
；
7.
呼叫接续：从
SRVCC
终端切换到
2G/TD
到进端
IMS
终端切换媒
体完成。
eSRVCC
切换
eSRVCC
基本原理
通过拜访地增加锚定节点，缩短媒体更新路径，
eSRVCC
实现了不超
300ms
的切换性能要
< br>求。
●
信令面在用户所在本地
网络锚定，
媒体面切换也在本地进行，
不需要通知远端切换媒体
面，
通常不超过
100ms
，避免了可
能的语音中断（约
800ms
），空口切换带来的语音中断无法
避免（约
200ms
）。
ATCF
功能
●ATCF
决定是否需要对媒体面会话进行锚定
●
执行会话切换，并控制媒体面的切换
●
切换时根据
ATU
< br>-STI
通知
SCC AS
发生
了
SRVCC
切换
●
分配可路由标识
STN-SR
ATGW
功能
●
在
ATCF
的控制下对媒体面进行
锚定和释放
MME
功能
●
从
HSS
获取
STN-SR
，切换时通过
Sv
接口
转发给
eMSC
●
将
UE
的
SRVCC capability
发送给
HSS
，用于后续锚定判断
●
发起目标小区的
SRVC
C
切换
●
协
调
PS
切换和
SRVCC
切换同步执行
eMSC
功能
●
由
MME Sv
接口的消息触发预留
CS
域资源
●ATCF
发起会话切换
●
选择发现
ATCF
SCC
AS
功能
●
锚定和关联会话
●
确定是否使用
eSRVCC
●
提供
C-MSISDN
和
ATU-
STI
等信息，用于路由和绑定会话
eSRVCC
的几个关键点
网络如何获取
UE
< br>的
SRVCC
能力？
●SRVCC
能力的
UE
附着时，
NAS
信令中的
MS
network capability
携带该能力至
MME<
/p>
，但
此时
IMS
仍不知道
UE
的能力。
●
当
UE<
/p>
进行
IMS
注册时，由亍
SCC AS
需通过
ISD
流
程将
STN-SR
推送到
MME
上，复用该
流程的应答消息将
SRVCC
能力送到
HSS
和
SCC AS
上，该流程对后续的域选择等方案至关
重要。
负责锚定功能的几个网元相互之间如何
发现和关联两个域的呼叫？
●eMSC
和
SCC
AS
通过
STN-
SR
发现拜访地的
ATCF
●ATCF
收到
ATU-
STI
决定锚定媒体，并在切换时通知归属地的
SCC AS
●ATCF
根据
C-MSISDN
关联切换后的电路域呼叫和原
IMS
用户的
呼叫
▊
eSRVCC
切换前后的信令流程
1.
支持
eSRVCC
的
< br>UE
注册流程
支持
eSRVCC
的
UE<
/p>
在
IMS
网络的基本注册流程与普通
LTE
终端在
IMS
网络的基本注册流
程类似，差异在于
P-CSCF
与
I-CSCF
之间会增加一跳
< br>ATCF
，后续所有流经
P-CSCF
< br>的消息
都会经过
ATCF
转发。
关键处理步骤：
< br>P1
：
P-CSCF/ATCF
收到
UE
的
REGISTER
消息后，
判断此呼叫后续有可能发生
eSRVC
C
切换，
则分配一个
STN-SR
号码，在
REGISTER
消息中增加
Feature-Caps
头域，并将其转发给
I-CSCF
。
Feature-
Caps
头域的关键参数如下：
●+
：
STN-
SR
号码，用于
eSRVCC IWF
后续寻址
ATCF
。
●+
-mgmt
：
ATCF
的
PSI
号码，用于
SCC AS
后续寻址
< br>ATCF
。
●+
-path
：
ATC
F URI
号码，
用于接受后续
SCC
AS
发送的
SIP MESSAGE
请
求
（其
中携带
eSRVCC
相关信息）
P2<
/p>
：
UE
收到
40
1
响应后，
重新构造
REGISTER
消息，
携带
RAND
< br>和
RES
，
发送给
S-CSCF
。
P-CSCF/ATCF
对其的处理与
P1
步骤相同。
UE
在
IMS
网络完成基本注册后，
S-CSCF
根据
HSS
上用户签约的
iF
C
模板数据，向
SCC
AS
发起第三方注册。对于分离的
IMS-
HSS
与
EPS-
SS
方案，消息流程如下所示：
P1-P5
：
SCC
AS
根据消息中
Feature-Caps
头域的
+-mgmt
标识，
判断<
/p>
UE
需要使
用
e
SRVCC
流程，则发送
UDR
消息到
EPS-SS
，请求下载用户的
eSR
VCC
能力、
STN-SR
号
码和
C-MSISDN
号码。
< br>
P6
：
EPS-SS
< br>通过
UDA
响应将用户的
eSR
VCC
信息返回给
SCC
AS
。
P7-P10
：
SCC AS
通知
ATCF
将
eSR
VCC
相关信息（
ATU-STI
、<
/p>
C-MSISDN
）与
UE
的本次注
册信息进行绑定
P11
：
SCC
AS
向
EPS-SS
发送
PUR
消息通知更新
STN-
SR
号码。
P12
：
EPS-SS
返回成功接收响应
PUA
。
P13
：
EPS-
SS
判断消息中携带的
STN-
SR
号码等与本地保存的
STN-SR
号码等信息不一致，
则将消息中携带的
STN-SR
号码等发送给
MME
。
P14
：
M
ME
更新本地的
STN-
SR
等号码后，向
EPS-
SS
返回成功更新响应。
2.
支持
eSRVCC
的
UE
主叫流程
同
IMS
基
本呼叫相比，只描述关键部分：
P
1
：
UE_A
发起会话，向
IMS
拜访网络入口
P-CSCF
发送
INVITE
消息。
P2
：
P-
CSCF/ATCF
收到
INVITE
消息后，判断需要锚定此会话，则进行本端媒体资源预留，
并将
INVITE
消息发送到
S-CSCF
。如果该会话的注册信息已绑定了
eSRVCC
相关信息，则<
/p>
P-CSCF/ATCF
也将该会话与
e
SRVCC
相关信息相绑定。
<
/p>
P3
～
P4
：<
/p>
S-CSCF
收到
INVITE
消息后，根据主叫用户签约的
iFC
模板数据，
触发
SCC AS
。
P5
～
P6
：
S-CSCF
将呼叫接续到被叫侧。
P7
：
S-
CSCF
收到被叫侧的
183
响应后，
将其转发给
SCC AS
。
P8
：
SCC AS
< br>收到
183
响应后，做如下处理：
1)
判断主叫用户是否已在
IMS-
HSS
签约了
STN-SR
号码和
C-MSISDN
号码。
如是，
则在
183
响应中增加
F
eature-Caps
头域，表明该会话被
SCC
AS
锚定。
2)
将
183
响应发送给
S-C
SCF
。
P9
：
P-CSCF/ATCF
收到
S-CSCF
转发的
183
响应，发现其中携带
+
标识，则记
录该标识与该会话的关联。
P10
：
UE_A
收到
183
响应，发现其中携带
Feature-Ca
ps
头域和
+
标识，则记
录该会话支持
eSRVCC
切换。
< br>
P11
～
P12
：
S-CSCF
收到被
叫侧针对
INVITE
请求的
200
OK
后，将其转发给
SCC
AS
。
P13
：
SCC
AS
收到
200
OK
后将
200 OK
发送给
S-CSCF
。
P1
4
～
P15
：
UE_A
收到
200
OK
。
<
/p>
的
VoLTE
被叫流程
< br>
P1
：被叫侧
I-CSCF
收到初始会话请求。
P2
：
I-
CSCF
将
INVITE
消息转发到被
叫用户注册的
S-CSCF
。
P3
：
S-
CSCF
收到
INVITE
消息后，根
据被叫用户签约的
iFC
模板数据，触发
SCC AS
。
P4
：
SCC AS
< br>收到
INVITE
消息后，做如下处理：
1)
判断被叫用户是否已分配
STN-SR
号码和
C-MSISDN
号码。
如是，
则在
INVITE
消息中增
加
Feature-
Caps
头域，表明该会话被
SCC
AS
锚定。
2)
将
INVITE
消息发送给
S-CSCF
。其中，关键参数如下：
●Feature
-Caps
头域：携带
+
标识，表示该会话被
SCC AS
锚定。
P5
：
S-
CSCF
将
INVITE
消息发送到<
/p>
P-CSCF/ATCF
。
P6
：
P-
CSCF/ATCF
收到
INVITE
消息后，判断需要锚定此会话，则进行本端媒体资源预留，
并将
INVITE
消息发送给
UE_B
。<
/p>
P7
：<
/p>
UE_B
收到
INVITE
消息，发现其中携带
Feature-Caps
头域
和
+
标识，则
记录该会话支持
eSRVCC
切换，并返回
183
响应。
P8
～
P9
：
P-CSCF
/ATCF
将
183
响应通过
S-CSCF
发送到
SCC
AS
。
P10
～
P11
：
SCC AS
收到
183
响应，并将其返回给主叫侧。
P12
～
P16
：
UE_B
向主叫侧返回
< br>200 OK
。
4. UE
的
eSRVCC
切换流程
eSRVCC
过程可以分为以下过程：
1.
切换判断：
eNodeB
根据
UE
上传的测量
报告（包括
E-UTRAN
网络下的小区信号测量报告
以及邻近的
UTRAN/GERAN
网络的信号
测量报告），判断是否进行接入网切换。
2.
切换过程：
a)eNodeB
判断需要切换接入
网后，向源
MME
发送
handove
r required
消息。
MME
根
据消
息里的
eSRVCC
指示，将
QCI=1
的语音承载和其他承载分离，同时根据切换请求消息中的
Target
ID
选择一个
eSRVCC IWF
，
通过
Sv
接口向其发起
PS to
CS Request
切换请求。该
消息中携带了之前
ATCF
为
UE
分配的
STN-SR
号码。
b)eSRVCC
IWF
收到切换请求消息后，根据消息中携带的
Target
ID
，找到目标
MSC
Server
（即切换目标侧所属
MSC Server
）
，
然后在
eSRV
CC IWF
和目标
MSC Server
间执行切换流
程。目标侧
UTRAN/GERAN
网络的承载建立完成后，
eSRVCC
IWF
根据
STN-
SR
号码，建立
eSRVCC IWF
和
ATCF/ATGW
的承载。
c)ATCF
根据
< br>C-MSISDN
关联用户待切换的会话，更新
ATGW
上的承载信息，将本端媒体面
切换为
U
TRAN/GERAN
网络的承载，并通知
SCC AS
更新
UE
的接入域信息。
eSRVCC
方案相对于<
/p>
SRVCC
方案的优化在于减少了切换时长，确保切换时长小于<
/p>
300ms
。
由于
SRVCC
方案中，影响切换时长的主要因素是在
IMS
网络中创建新承载的过程，因此，
eSRVCC
相比于
SRVCC
优化的核心放在新承载创建路径上，如下
图所示。
SRVCC
方案：媒体的切换点是对端网络设备（如对端
UE
）
，本端接入网络发生变更后，需
要将变更后的本端承载设备地址等信息发送给对端网络设
备，进行承载地址的更新。
<
/p>
eSRVCC
方案：媒体切换点改为更靠近本端的设备，以减少变
更消息传输时长。具体方案就
是在
P-CSCF
与
I-CSCF/S-CSCF
之间增加
ATCF/ATGW
功能实体
（在华为提供的
eSRVCC
切
换解决方案中，由
SBC
实现
ATCF/ATGW
< br>功能），作为媒体锚定点，无论是切换前还是切
换后的会话消息都要经过
ATCF/ATGW
转发。后续在发生
eSRV
CC
切换时，只需要创建
UE
与
ATGW
之间的承载通道，对端设备与
ATG
W
之间的媒体流还是通过原承载通道传输。
eSRVCC
方案中创建新承载通道
的消息交互路径明显短于
SRVCC
方案，因此
eSRVCC
方案
相比
SRV
CC
方案减少了切换时长。以下描述通话后的切换流程。
P1
：
UE
_A
和
UE_B
正在进行一个
Active
状态的会话，
媒体锚定在
ATCF/SBC
。
UE_A
< br>根据当
前所在地区
E-UTRAN
网络和
UTRAN/GERAN
网络的信号强度，向
eNodeB
上传系统测量报
告。
eNodeB
经过判断决定切换后，向
MME
发送切换请求
Handover
Request
消息；
P2
：
MME
向
UE_A
当前所在地区的
eSRVCC IWF
发起
eSRVCC
切换请求
PS to CS Request
消息。
P3
～
P4
：
eSRVCC IWF
向
MME
返回
PS to CS Response
消息。
MME
收到消息后，
指示
UE_A
-
-
-
-
-
-
-
-
-
上一篇：Xilinx FPGA配置的一些细节
下一篇：宝葫芦的秘密读后感范文10篇