VoLTE端到端业务质量分析xRVCC切换分析研究.docx
- 文档编号:29458824
- 上传时间:2023-07-23
- 格式:DOCX
- 页数:28
- 大小:3.38MB
VoLTE端到端业务质量分析xRVCC切换分析研究.docx
《VoLTE端到端业务质量分析xRVCC切换分析研究.docx》由会员分享,可在线阅读,更多相关《VoLTE端到端业务质量分析xRVCC切换分析研究.docx(28页珍藏版)》请在冰豆网上搜索。
VoLTE端到端业务质量分析xRVCC切换分析研究
VoLTE端到端质量分析
-xRVCC切换分析研究
项目名称
文档编号
版本号
部门
作者
版权所有
大唐移动通信设备有限公司
本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。
未经大唐移动书面授权,任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容,违者将被依法追究责任。
1.xSRVCC专项分析背景
2016年中国移动集团开展VoLTE百日会战后,全国各个省公司陆续开始放号进行VOLTE商用,针对当前LTE网络发展的趋势,会逐渐进行大规模放号,考虑到我司区域还存在着大量的不连续覆盖问题,那么今后的语音业务质量,会对xSRVCC性能的可靠性提出非常高的要求,该指标的好坏直接关系到用户的感知问题,也会影响到我司在同区域友商竞争中地位。
目前集团也下发了关于质差小区(性能指标和用户感知)考核的建议,各个省公司已经陆续开始考核质差TOP小区,其中就包含XSRVCC切换,特通过此专项提升现网用户感知。
2.xSRVCC切换分类
在集团指标功能中:
xSRVCC指标包含aSRVCC/baSRVCC/aSRVCC三种。
bSRVCC定义:
从INVITE-Request到振铃Ringing180之间系统间切换
aSRVCC定义:
从Ringing180到接通INVITE-OK(200)之间系统间切换
eSRVCC定义:
接通后的系统间切换
目前3GPP协议规范对bSRVCC切换未做明确功能实现描述,各厂商现有系统的bSRVCC功能均未开发实现,现网实测中发现在LTE弱场下存在概率性触发bSRVCC导致无法接通的现象,此项功能的支撑对提升现网VoLTE感知非常关键。
3.xSRVCC切换指标统计方式
3.1、SRVCC切换流程
SRVCC(SingleRadioVoiceCallContinuity):
主要解决当单射频UE在LTE网络和2G/3G网络之间移动时,如何保持语音业务连续性的问题,也就是单射频UE在IMS控制的VoIP语音和CS语音之间无缝切换。
SRVCC关键技术点:
1.在MSCServer和MME之间定义Sv接口,提供异构网络间接入层切换控制;
2.通过设置IWF互通网元,终结Sv接口,避免对原有电路域设备的改造;
3.IMS网络作为会话锚定点,统一进行会话层切换,保证会话跨网切换的连续性。
3.2、OMC网管相关KPI介绍
备注:
①、到GERAN的SRVCC切换出请求次数
②、到GERAN的SRVCC切换出准备成功次数
③、到GERAN的SRVCC切换出执行请求次数
④、到GERAN的SRVCC切换出成功次数
SRVCC成功率=(到GERAN的SRVCC切换出成功次数/到GERAN的SRVCC切换出请求次数)*100
3.3、平台相关KPI介绍
Ø指标名称:
SRVCC切换成功率
Ø英文名称:
Service.VOLTE.SrvccHandoverSuccRate
Ø业务需求:
用户移出LTE覆盖时需要切换到2G的成功几率。
Ø指标定义:
终端在VoLTE通话过程中进行移动,当移出LTE覆盖时需要切换到2G,该指标标识这种切换的成功比例。
a)指标算法:
。
ØSRVCC切换成功次数:
eMSC向MME发送Handovercomplete(下图消息5),且收到IMS核心网ATCF的200OK(下图消息4)的次数。
ØSRVCC切换请求次数:
eMSC收到MME的PStoCSHandoverRequest(下图消息1)的次数。
Ø测量数据映射关系:
SvxDR,
ŸSRVCC切换成功次数:
xDR中字段“Interface”=Sv,且“ProcedureType”=1,且“RESULT”=0的xDR个数。
ŸSRVCC切换请求次数:
xDR中字段“Interface”=Sv,且“ProcedureType”=1,的xDR个数
Ø数据类型:
实型
Ø数据单位:
无
Ø空间粒度:
UE
Ø时间粒度:
15分钟
Ø数据来源:
Sv
网优平台---分母:
handoverrequired(S1接口),分子:
携带successfulhandover的UEContextReleaseCommand(S1接口)
信令平台---分母:
PSTOCSHandoverrequest(Sv接口),分子:
PStoCSCompleteAcknowledge(Sv接口)
根据算法可以看出,网优平台是以S1接口进行打点,信令平台是以Sv接口进行打点。
算法上存在差异。
4.xSRVCC切换指标分析思路
首先需要分解到三域(即为EPC\IMS\CS),再通过关联分析,聚类分析,原因分析,定界到8个维度
4.1质差定界
观察关联KPI指标质差情况,对质差KPI指标进行时域对比,聚类对比,对失败原因值进行分析,确定质差方向:
ECP域质差网元,IMS域质差网元,CS域质量网元
4.2质差定位
如上问题定界定界后,需要进一步,以其他TOPN失败原因值关联定位,在平台,CDL进行汇聚分析出各个维度。
5.OMC与信令平台匹配统计方法
从网管中提取到的KPI指标必须是15分钟粒度的,粒度太大在信令平台S1很难提取到,在SV口信令是可以提取到的,所以要在提取OMC15中粒度要与信令平台要进行匹配,便与统计分析
5.1、信令平台分析思路:
如果srvcc在S1口失败,没有在Sv口发起切换,那么信令平台针对Sv的统计里是看不到的。
下面我们根据这种情况给出具体的,使用信令平台的核对办法。
针对网优平台给出的srvcc质差小区,在S1AP记录分析中,设置如下几个条件:
Ø设置ECI=网优提供的小区
Ø设置切换类型=[2]ltetogeran,即srvcc
Ø查询结果如下图所示,在S1接口失败的那次,就不会有Sv接口的消
Ø点开信令,进行S1接口失败的srvcc详细分析
Ø针对S1接口成功的,在Sv接口失败的,在切换记录分析中,设置如下几个条件:
Ø设置ECI=网优提供的小区
Ø查询结果如下图所示,红框中即为Sv接口失败的消息
Ø点开信令,进行Sv接口失败的srvcc详细分析
5.2、Esrvcc与Xsrvcc统计说明:
在集团指标功能中,我们严格按照集团下发的定义,仅统计了esrvcc的切换次数及切换成功率。
下文将说明,如何在信令平台上如何进行Xsrvcc的统计(包含asrvcc/bsrvcc/esrvcc)
在KPI小区分析功能中,是我们针对现网实际需求,进行的小区维度指标统计,其中我们包含了xsrvcc的统计和esrvcc的统计。
如下图可以看到xsrvcc与esrvcc的数据对比。
这个数据的打点是以sv口进行打点,与网游平台的s1口打点会有差异,请悉知。
6.xSRVCC案例介绍
案例1:
切换与挂机流程冲突-用户行为(终端发Cancel)
【问题描述】:
LTE-Tdd小区
CGI
切换至2G成功次数
切换至2G请求次数
失败次数
DX通渭贾家峡-LTE-F(四期)-1
460-00-773436-1
2
33
31
【问题分析】
通过炎强平台信令可以看到,源小区在08:
53:
11时,eNB向MME发送S1HandoverRequired,包含信息如下图:
在后续的流程中,eMSC和MME之间未进行SRVCCPStoCSComplete信令交互,导致eNB和MME之间进行UEContextRelease,所以在不到1s的时间内,eNB再次向MME发起S1HandoverRequired如下:
eNB向MEE发送HandoverRequired之后,MME未给eNB发送HandoverCommand,在超过3s(切换准备定时器时长)之后,eNB给MME发送HandoverCancel,失败原因如下:
后续所有失败的原因均集中在这2个问题上,1、MME向eNB发送了HandoverCommand,但是没有后续的UEContextRelase;2、MME未向eNB发送HandoverCommand,导致切换准备定时器超时,eNB向MME发送了HandoverCancel。
【解决措施】
【解决计划】
【PCAP记录包】
案例2:
切换与挂机流程冲突-用户行为(终端发Bye)
【问题描述】
LTE-Tdd小区
CGI
切换至2G成功次数
切换至2G请求次数
失败次数
DX渭源会川-LTE-F(二期)-3
460-00-615722-3
7
11
4
【问题分析】
从炎强平台信令可以看到,在12:
49:
36时,eNB向MME发起HandoverRequired,包含信息如下:
在eNB给MME发完HandoverRequired,紧接着在12:
49:
36时,UE向SBC发起了BYE小区,切换流程和挂机流程冲突,导致切换失败,如下:
在后续的流程中,因切换定时器超时,导致了一次失败,如下:
【解决措施】
【解决计划】
【PCAP记录包】
案例3:
GSM资源不足问题:
no-radio-resources-available-in-target-cell
【问题描述】:
LTE-Tdd小区
小区CGI
切换至2G成功次数
切换至2G请求次数
切换至2G失败次数
SRVCC成功率
邵家塘LTE-1
460-00-776793-1
2
8
6
25.00%
【问题分析】
SDCCH分配成功率
TCH分配成功率(不含切换)(%)
随机接入成功率%
忙时SDCCH溢出总次数
信令信道拥塞率(%)
忙时话音信道溢出总次数(不含切换)
忙时话音信道溢出总次数(含切换)
话音信道拥塞率(不含切换)(%)
无线接入性
89.87%
100.00%
89.87%
32
10.13%
0
0
0.00%
89.87%
82.27%
58.33%
82.27%
53
17.73%
5
18
41.67%
47.99%
90.31%
100.00%
90.31%
28
9.69%
0
0
0.00%
90.31%
案例4:
GSM站点退服导致GTPV2响应失败FailurewithTargetsystem
S1失败原因为:
[106]ho-failure-in-target-EPC-eNB-or-target-system
GTPV2失败原因为[73]Noresourcesavailable
日期
开始
结束
LAC_CI
可用信道数
TCH信道数
SD信道数
SD最大占用数
信道可用率
SDCCH溢出次数
SDCCH溢出率
2016/09/05
14:
00
15:
00
37931_2204
19
17
12
11
48.05%
3
0.21%
2016/09/05
14:
00
15:
00
37931_2205
19
17
17
4
41.46%
0
0.00%
2016/09/05
14:
00
15:
00
37931_2206
16
14
10
7
52.00%
6
1.12%
案例5:
MME、eMSC漏配GSM侧LAC导致对应LAC区域换成功率0%
【问题描述】
甘肃7月份VoLTE已经商用,近期省网管中心通报全省eSRVCC切换指标极差,大唐区域主要集中在定西,根据省公司通报的TOP,我们发现定西的eSRVCC失败主要集中在通渭区域,为此我们结合我司的分析工具CDL和省移动的信令平台,详细分析该区域的eSRVCC切换失败原因。
【问题分析】
根据信令平台统计,我们对eSRVCC失败率高的小区进行了详细的分析,根据手机号码对小区统计的eSRVCC取消。
从当前TOP小区的失败原因来看,eSRVCC失败有三种原因:
✧Cause:
TargetCellnotavailable;
✧Cause:
Noresourcesavailable;
✧Cause:
Handover/Relocationcancelledbysourcesystem ;
(注:
OMT统计信令口味是S1口、信令平台是SV口)
针对定西通渭区域eSRVCC失败的问题,无论是信令平台,还是CDL分析,eSRVCC的失败原因均为unknown-targetID,我们从无线侧的参数、邻区配置、干扰、告警、MR等进行了详细的核查,均无问题。
通过一周的指标对比分析,失败的区域主要集中的LAC区域:
37933;我们转向怀疑是否是MME侧添加的数据有问题;随后我们在找一下华为MME是否漏配了该LAC导致(定西29个LAC中问题收敛在37933,该LAC下挂43个站点,其中有37个站点出现只有请求次数,成功次数为“0”),问题收敛在定西LAC=37933,见下:
区域
网元
eNBID
SRVCC.SuccOutGeran(R091_004)
SRVCC.AttOutGeran(R091_001)
LTE现网LAC
通渭
DX通渭地八-LTE-F(四期)-3
777695
0
309
37933
通渭
DX通渭团结-LTE-F(四期)-3
777905
0
241
37933
通渭
DX通渭姚岔-LTE-F(四期)-3
777912
0
186
37933
通渭
DX通渭积麻-LTE-F(四期)-3
777561
0
172
37933
通渭
DX通渭文川-LTE-F(二期增补)-2
615901
0
105
37933
通渭
DX通渭桃园-LTE-F(四期)-2
777544
0
66
37933
通渭
DX通渭阳坡-LTE-F(三期)-1
766572
0
49
37933
通渭
DX通渭南河-LTE-F(四期)-3
777571
0
44
37933
通渭
DX通渭李坡-LTE-F(四期)-1
777575
0
34
37933
通渭
DX通渭榜罗-LTE-F(四期二)-1
777938
0
31
37933
通渭
DX通渭榜罗-LTE-F(四期二)-2
777938
0
31
37933
通渭
DX通渭常河明山-LTE-F(四期)-1
777639
0
29
37933
通渭
DX通渭张川-LTE-F(四期)-1
777814
0
26
37933
通渭
DX通渭大庄-LTE-F(四期)-3
777542
0
22
37933
通渭
DX通渭合并-LTE-F(四期)-2
777506
0
16
37933
通渭
DX通渭桃园-LTE-F(四期)-3
777544
0
15
37933
通渭
DX通渭张坪-LTE-F(四期)-3
766902
0
10
37933
通渭
DX通渭张坪-LTE-F(四期)-2
766902
0
9
37933
通渭
DX通渭榜罗中学-LTE-F(二期)-2
615701
0
9
37933
通渭
DX通渭刘家岘-LTE-F(四期)-3
777861
0
8
37933
通渭
DX通渭地八-LTE-F(四期)-1
777695
0
8
37933
通渭
DX通渭大庄-LTE-F(四期)-2
777542
0
8
37933
通渭
DX通渭大庄-LTE-F(四期)-1
777542
0
7
37933
通渭
DX通渭文川-LTE-F(二期增补)-3
615901
0
7
37933
通渭
DX通渭常河南山-LTE-F(二期)-3
615703
0
4
37933
通渭
DX通渭文树-LTE-F(四期)-1
777576
0
4
37933
通渭
DX通渭小庄-LTE-F(三期)-3
660883
0
4
37933
通渭
DX通渭红岘-LTE-F(四期二)-1
659683
0
2
37933
通渭
DX通渭小庄-LTE-F(三期)-2
660883
0
2
37933
通渭
DX通渭榜罗四平-LTE-F(四期二)-1
660802
0
2
37933
通渭
DX通渭榜罗-LTE-F(二期)-1
615702
0
2
37933
CDL信令分析截图如下:
分析通渭差小区的CDL日志,ENB--MME在发起S1 Handover Required 后 MME直接回复S1 Handover Preparation Failure 原因为:
value S1AP-PDU :
:
= unsuccessfulOutcome :
{
procedureCode 0,
criticality reject,
value HandoverPreparationFailure :
{
protocolIEs
{
{
id 0,
criticality ignore,
value MME-UE-S1AP-ID :
25208088
},
{
id 8,
criticality ignore,
value ENB-UE-S1AP-ID :
136
},
{
id 2,
criticality ignore,
value Cause :
radioNetwork :
unknown-targetID
}
}
}
}
从下图看到,eNB上发S1HandoverRequired携带的GSMLAC小区未37933,见下:
EPC在收到S1HandoverRequired后,下发Failure消息,原因值为“该小区不存在”,见下图:
信令信令平台分析截图如下:
通过信令平台信令失败原因为 radioNetwork :
unknown-targetID,见下:
切换类型,LACCI见下:
【解决措施】
通过CDL以及信令平台信令分析,我们对eSRVCC失败的无线环境、当前小区的干扰、MR、影响指标的告警等问题一一排除后,结合小区失败的原因以及问题失败的区域集中性等,由此基本可以确认,定西通渭的eSRVCC失败主要系MME侧漏配了定西的LAC:
37933,导致该LAC下面的eSRVCC 切换失败率为100%,联系核心网侧人员进行确认,的确是MME未添加定西的LAC:
37933,在核心网侧添加该LAC完毕后,我们观察eSRVCC切换指标并未恢复正常,我们联系核心网做二次检查,怀疑除MME外,可能还有其他网元存在漏配数据的可能,核心网侧核查发现出MME外,eMSC也漏陪定西LAC=37933数据,eSMC数据添加后,进一步观察eSRVCC指标,可以看到指标已恢复正常。
见下:
日期
SRVCC.SuccOutGeran(R091_004)
SRVCC.AttOutGeran(R091_001)
失败次数
eSRVCC切换成功率
调整前
2016.08.04
127
399
272
31.83%
2016.08.05
87
467
380
18.63%
2016.08.06
107
503
396
21.27%
2016.08.07
72
267
195
26.97%
2016.08.08
87
235
148
37.02%
2016.08.09
183
435
252
42.07%
调整后
2016.08.12
176
181
5
97.24%
2016.08.13
197
205
8
96.10%
2016.08.14
216
248
32
87.10%
2016.08.15
198
212
14
93.40%
2016.08.16
138
151
13
91.39%
2016.08.17
172
184
12
93.48%
2016.08.18
131
149
18
87.92%
案例6:
interaction-with-other-procedure-IMS域与CS域业务并发
【问题描述】
LTE-Tdd小区
小区CGI
切换至2G成功次数
切换至2G请求次数
SRVCC成功率
失败次数
连城铝厂LTE-2
460-00-607454-2
8
10
80.00%
2
【问题分析】
对象标识
时间
SRVCC.SuccOutGeran(R091_004)[单位:
次]
SRVCC.AttOutGeran(R091_001)[单位:
次]
失败次数
连城铝厂LTE-2(PLMN=1,AREA=8,ENB=607454,cell=2)
2016.09.0508:
45-2016.09.0509:
00
3
5
2
通过炎强平台信令S1口信令可以看到08:
49:
12eNB连续两次向MMe发起切换请求,均被MMe直接拒绝,拒绝原因为interaction-with-other-procedure(29),业务并发;
SV口信令08:
49:
08SBC发送180Ringing给主叫UE,08:
49:
12eNB连续两次向MME发送切换请求但均被MME拒绝,拒绝原因为interaction-with-other-procedure(29),业务并发,08:
49:
16SBC发送200ok消息给主叫UE,振铃与接通之间相隔8秒,由于切换请求与180Ringing并发,导致切换失败,接通延时。
【解决措施】协调MME,在IMS域会话过程中,为何出现CS域的信令导致业务并发失败
【解决计划】
【PCAP记录包】
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- VoLTE 端到端 业务 质量 分析 xRVCC 切换 分析研究
![提示](https://static.bdocx.com/images/bang_tan.gif)