C114门户论坛百科APPEN| 举报 切换到宽版

亚星游戏官网

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索
查看: 21512|回复: 3

[技术讨论] VoLTE语音MOS测试办法 [复制链接]

军衔等级:

亚星游戏官网-yaxin222  新兵

注册:2011-12-2
发表于 2016-10-19 11:23:02 |显示全部楼层
一、VoLTE语音MOS采样点机制
VoLTE语音MOS采样机制如下:
(1)主叫起呼,进行录音(8s左右);
(2)被叫放音,主叫收音,被叫记录第1个MOS采样点(8s);
(3)主叫放音,被叫收音,主叫记录第1个MOS采样点(8s);
(4)被叫放音,主叫收音,被叫记录第2个MOS采样点(8s,与第1个采样点间隔16s);
(5)主叫放音,被叫收音,主叫记录第2个MOS采样点(8s,与第1个采样点间隔16s);
(6)被叫放音,主叫收音,被叫记录第3个MOS采样点(8s),如此类推??
二、VoLTE语音MOS优化分析方法
1、MOS差的问题点定位
测试log单次通话连续两个采样点MOS值小于3的问题点定义为MOS差的问题点。
注意事项:需剔除通话结束的最后一个采样点与下次通话第一个采样点的MOS值都小于3的问题点。
2、MOS优化分析方法
由MOS采样点机制可以看出,MOS采样点收集的是采样时间点前8秒的语音质量,所以在分析的时候,需着重分析MOS采样时间前8秒UE本端的下行(包括:无线环境、语音编码、抖动、丢包、频繁切换、RRC重建、异频测量频次等),以及对端的上行(包括:频繁切换、RRC重建、异频测量频次等)。
三、VoLTE语音MOS值的影响因素及优化思路
1、MOS值的影响因素
MOS值的直接影响因素为:端到端时延、抖动、丢包;
VoLTE端到端时延可以分解为:UE语音编/解码时延、空口传输时延、核心网的处理时延、传输网的传输时延。丢包和抖动的影响因素包括:空口信号质量、eNB负载、传输网的丢包和抖动。
故将以上因素分解后,MOS的影响因素包括:语音编码、覆盖、干扰、切换、邻区、基站负荷、基站故障、传输、核心网、测试终端、人为操作失误等。
2、MOS值的优化思路
结合以上影响因素和前期VoLTE拉网测试时遇到的MOS问题,共总结出四类问题点类型:无线问题、基站异常、测试规范和设备、核心网/传输。
在分析MOS问题时,大家首先要考虑基站是否正常工作,其次考虑测试是否规范、测试设备是否正常,再次判断是否为无线问题造成的,最后才考虑是否核心网及传输网引起的。
因此大家在分析MOS问题时,应该按以下步骤进行MOS优化:
(1)基站问题:
是指问题路段中心经纬度150米以内的基站及主瓣65度范围的小区,若存在基站负荷过大、影响业务的告警、断站等问题,必将影响MOS值。处理方法:在测试前确保基站正常工作。
案例1:基站故障导致MOS值低
问题描述:车辆由南向北行驶至清风路与两河大道交叉路口,UE占用金牛清淳一街-SCDHLS3HM3JN-D2的信
号,无线环境RSRP为-116.81dbm,SINR为-2.5,MOS值1.14,经测试数据分析,发现UE未能收到距离清风路与两河大道交叉路口50米的华力汽车企业车队-SCDHLD3HM2GX站点信号,经查询告警得知,发现该站点网元断链,因而导致该路段出现弱覆盖现象,最终导致MOS值差。
处理建议:建议处理华力汽车企业车队-SCDHLD3HM2GX站点故障。
案例2:基站负荷过大,导致MOS值低
问题描述:无线环境较好(RSRP为-95dBm左右,SINR为10左右),无频繁切换;但MOS打点前8s主被
叫占用电子科大-SCDHLS0HM1CH-D5,抖动和丢包均比较异常(RTP Jitter为992ms,RTP Loss Rate为3.99%),后台查询电子科大-SCDHLS0HM1CH-D5问题发生时间点15分钟粒度的上行PRB峰值利用率为65.145%,上行PRB平均利用率为45.949%,初步判断为基站负荷过大导致调度不及时,从而影响了MOS值。
处理建议:解决电子科大-SCDHLS0HM1CH-D5负荷过大的问题。
(2)测试规范/测试设备:
包括MOS设备调试造成的MOS设备性能低、MOS差、音频线松动、终端异常等。处理方法:在测试前确保MOS设备正常工作、事先调试好MOS值、音频线插紧、检查终端等。案例1:调试MOS导致MOS值低
问题描述:周围站点状态正常,无线环境良好;本次问题发生在1月25日下午第一个正式log的第1次至
第3次呼叫,连续21个MOS值均低于1.5(覆盖较好,无干扰和故障),车辆一直停留在北京华联双桥店门口,第4次起呼MOS值恢复正常,初步判断为当天下午刚开始测试时MOS设备有
问题导致。
处理建议:建议按测试规范进行测试,测试前确保MOS设备正常工作。
案例2: 无线环境良好,MOS采样点前8s信令丢失
问题描述:周围站点状态正常,无线环境良好;主叫9:29:35发起INVITE请求,9:32:28出现低MOS,分
析主叫前8s测试数据,此时占用春良宾馆-SCDHLD3HM3JJ-F3,此时RSRP=-87.25dbm,SINR=17,
9:32:20至9:32:28主叫无信令交换,查看9:32:20无RTP丢包异常,RTP抖动正常,分析被叫
LOG,无信令。初步判断为终端问题导致MOS差。
处理建议:建议按测试规范进行测试,测试前确保UE终端正常工作。
(3)无线问题:
主要包括弱覆盖(RSRP<-100dBm,SINR<0)、质差(RSRP>-100dBm,SINR<0)、频繁切换等。
引起弱覆盖的原因包括:周边缺站(需新规划)、已规划站点但未建设、周边基站故障、室分泄露、邻区漏配、切换参数不当。
质差包括弱覆盖质差和强覆盖质差,前者优先处理弱覆盖,后者通常是由MOD3干扰、GPS失步引起的干扰、外部干扰等干扰引起的。
频繁切换通常是由于网络结构不合理、天馈接反、切换参数设置不当造成的。
案例1:周边缺站(需新规划),弱覆盖导致MOS值低
问题描述:测试车辆在川建路由西向东行驶,主被叫占用灵润路8号-SCDHLD3HM3JN-F1、凤凰石油加油站
-SCDHLS2HM1JN-D3通话(RSRP-94~-115、SINR-9~15)邻区无更好接续小区,该路段为弱覆盖
(连续覆盖路段约180米RSRP<-105),无线环境差导致低MOS(时间为14:58:30至14:58:41、
14:59:11至14:59:45)。该路段凤凰石油加油站-SCDHLS2HM1JN与汇泽路-SCDHLS3HM3JN站间
距为600米左右,站间距过大不能够保证有效覆盖;周边无规划站点。
处理建议:建议在川建路新建站点(经度104.06242,纬度30.73527)
案例2:已规划站点未建设,弱覆盖导致MOS值低
问题描述:主叫UE在成双大道占用桐希亨-SCDHLS1HM1WH-D3时MOS低,在16:09:49的MOS统计为2.076,
16秒后在16:10:04的MOS统计为1.401,UE所在路段周边小区的RSRP均在-105dbm左右,属于覆盖不足,核实在覆盖较差路段已有规划L3HZ156054簇桥老农管站,但未开通站点。
处理建议:建议尽快开通站点L3HZ156054簇桥老农管站。
案例3:周边站点故障,弱覆盖导致MOS值低
问题描述:在一环路北一段路段被叫占用汇龙湾广场-SCDHLS3HM3JN-F2小区(RSRP=-109dBm SINR=-10),
通过查询发现离问题路段最近的友纳克酒店-SCDHLS0HM1JN站点断站;
处理建议:尽快恢复友纳克酒店-SCDHLS0HM1JN站点故障。
案例4:室分泄露,弱覆盖导致MOS值低
问题描述:问题点前从“香伯伦酒店-SCDHLS0HM1JJ-D1”(RSRP为-101dBm,SINR为9)切换至室分小区
“长城锦苑-SCDHLS4WM3JJ-F1”(RSRP为-90dBm),之后由于无法切换出至室外宏站,弱覆盖
导致MOS值偏低。
处理建议:处理室分小区“长城锦苑-SCDHLS4WM3JJ-F1”的室分外泄问题。
案例5:邻区漏配,弱覆盖导致MOS值低
问题描述:周围站点状态正常;UE沿八里桥路至南向北后右过程中,由于2016/1/25测试时查看八里桥路
灯杆F-SCDHLD4HM3CH-F1到路段覆盖站点凤仪东路东端没有添加邻区关系,被叫UE占用八里桥
路灯杆F-SCDHLD4HM3CH-F1(RSRP=-103dBm SINR=-10),无法发生切换到合适的小区,被叫电
平质量较差且出现呼叫重建导致MOS质差
处理建议:添加八里桥路灯杆F-SCDHLD4HM3CH-F1到凤仪东路东端站点所有小区的邻区关系。
案例6:切换参数不当,弱覆盖导致MOS值低
问题描述:周围站点状态正常;辆沿新航路从西南向东北行驶,UE占用汇都工业园F-SCDHLS3HM2GX-F1的
信号RSRP为-96dbm左右,SINR10.4左右,MOS值为1.52.随着车辆继续行驶且信号不断减弱,而顺康电子-SCDHLS1HM1GX-F1的电平到达了-83dbm左右都未能与汇都工业园
F-SCDHLS3HM2GX-F1发生切换,因此因汇都工业园F-SCDHLS3HM2GX-F1与顺康电子
-SCDHLS1HM1GX-D切换不及时引起MOS值差;
处理建议:建议将汇都工业园F-SCDHLS3HM2GX-F1到顺康电子-SCDHLS1HM1GX-F1的小区偏移量CIO由0调
整到6dB,加快两者之间的切换。
案例7:切换参数设置不当,频繁切换导致MOS值低
问题描述:周围站点状态正常;测试车辆行驶至静渝路,由北向南行驶,主叫占用沙河农牧市场
异频测量对MOS的影响
在移动VOLTE拉网测试过程中出现了单点MOS分值降低的情况。针对低MOS分值点,对测试数据进行详细的数据分析,发现在异频测量开始后,MOS分值会有所降低,且异频测量周期越短,异频测量次数越多,对MOS的影响越大。
2      处理过程
2.1问题分析
在VOLTE语音通话中,UE进行端到端的语音包传送,同时对邻区进行测量。测量分为同频测量和异频测量,当达到异频测量门限时,eNODEB下发测量GAP相关配置,启动异频测量。
从空口信令分析,eNODEB下发测量控制,携带异频信息,UE收到后启动异频测量。在此过程中,MOS打分由3.5以上降低至3.5以下,说明启动异频测量对MOS会产生影响。如下图空口信令所示:

异频测量之所以会影响用户感知,主要原因如下图所示。UE在频率A进行VOLTE的语音通话,当启动异频测量后,UE要离开频率A到频率B上进行异频测量,这段时间将影响VOLTE语音包的传送,具体信息如下图所示:
测量GAP就是UE离开当前频点到其他频点测量的时间段。在异频测量期间,UE不进行服务小区的业务传输,因此异频测量会对VOLTE语音业务产生影响。所以测量GAP周期越短,单位时间内异频测量的次数越多,对语音业务用户感知的影响也越大。
2.2处理过程
测量GAP两种模式,一种TGAP为6ms,周期Tperiod为40ms;另一种TGAP为6ms,周期Tperiod为80ms,两种模式测量时间都是6ms,但周期不同。目前现网采用模式为策略二,即40ms为周期,测量周期短,单位时间内启动异频测量的次数较多。为提升用户感知,提高VOLTE语音测试MOS值,将测量GAPTperiod修改 80ms,延长异频测量的周期,减少单位时间内异频测量的次数,从而降低异频测量对MOS的影响程度。
2.3调整效果
对网格35进行调整GAP模式的对比测试,在修改异频测量周期为80ms后,对比VOLTE的相关路测指标,平均MOS打分由3.94提升到3.98,MOS3.0占比由97.02提升到97.67,RTP时延抖动由3.8减少到3.44,其他指标保持平稳。同时从测试数据分析,并没有产生延迟切换的现象。
·       异频测量时间点MOS评分对比
优化前异频起测过程LOG截图,MOS评分相对较低:

优化后异频起测过程LOG截图,MOS评分明显优于调整前:

·       优化前后指标对比:
接通率
掉话率
平均MOS
MOS大于3.0占比
IMS注册成功率
Esrvcc成功率
调整前
97.62
0
3.94
97.02
100
100
调整后
100
0
3.98
97.67
100
100
·       MOS评分变化                         
3  优化总结
通过调整异频测量GAP模式,异频测量周期由40ms调整至80ms,延长异频测量周期,减少单位时间内异频启测的次数,从而降低异频测量启动后对VOLTE语音MOS的影响程度,提高VOLTE语音用户的感知。同时在调整GAP模式后,对VOLTE语音通话中切换及时性没有造成影响,因此可以通过此调整改善用户VOLTE语音质量。
1.1 日常优化总结
日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化,功能优化四个方面着手,与ATU路网、工程建设紧密配合,提升整体网络质量。
1.2 RLC优先级优化
现象:呼叫建立与切换过程冲突,专载被MME释放。呼叫建立过程中专载建立与切换几乎同时发生,MME未收到NAS专载完成消息导致释放专载,终端回复invite580(也有上发CANCLE的情况),专载丢失形成未接通事件。
原因分析:QCI5设置的RLC优先级为2,高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早,但是因为优先级比MR和SIP低,未及时发送。
优化措施:降低QCI 5优先级,确保SIP消息及时上传,修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化
现象:终端业务建立过程中,出现SIP信息传递丢失的问题,导致收到网络下发的INVITE500或者580等原因值释放。
原因分析:UE在无线信道较差的情况下,SIP信令发送或接收不完整或者无法及时传递,导致IMS相关定时器超时而发起会话cancel。经过分析,由于QCI5的pdcp 丢弃时长过小,在无线覆盖较差的地方,上行时延会变大,容易导致QCI5信令丢包。

优化措施:
QCI5 PDCP DiscardTimer由300ms修改为无穷大
优化效果:
VoLTE无线接通率提升明显
1.4 SBC传输协议TCP重传次数优化
背景:被叫从2G返回4G后,主叫起呼,被叫首先bye消息,紧接着接连收到多条上一次呼叫的invite,被叫回复bye481\invite486\invite580,呼叫失败。
优化措施:爱立信SBC对TCP配置进行了修改:最大重传次数从15次改为5次,最大重传隔间从十几分钟改为15s,此类问题已解决。

1.5 系统间邻区优化
LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划,同时根据4G、2G道路测试数据匹配进行邻区补充:
4G弱信号路段与2G拉网服务小区匹配:利用第三方拉网测试数据,将4G和2G拉网信号强度、经纬度、服务小区等信息导出。通过经纬将4G弱信号(RSRP<-110dbm)与2G强信号(RXLOV>-95dbm)在50米范围内拟合,根据拟合度对2G邻区进行补漏工作。
剔除现网已配置的邻区关系,补漏邻区关系对后,eSRVCC切换提升明显,且由于2G邻区不准确导致的异系统重定向减少。
1.6 重定向掉话
XX区域掉话最严重属于重定向掉话,在XX基站算法中,以下三种可能发生重定向,重定向释放RRC后,专载同时被拆除,VoLTE业务产生掉话。
1.7 上行PUSCH功控参数优化
背景:xx区域拉网测试发现上行PUSCH发射功率偏高,对现网参数检查发现,xx区域上行希望功率值设置过高。
优化措施: 进行功控相关参数优化,
现网配置: p0NominalPUSCH =-75 ;puschPCAdjType=0
优化值: p0NominalPUSCH =-87 ;puschPCAdjType=2
●同等路损情况下,参数修改后,ue发射功率大约下降2~3dB。
●目前终端平均上行发射功率仍高于10db,仍需完善现有功控方式。
修改后,PUSCH TxPower(10dbm以上)占比由40%下降到30%左右。

1.8 RTP丢包率优化
背景:测试发现,XX区域RTP丢包率偏高,个别网格甚至达到2%以上。
原因分析:在无线质量较好的情况下基本无丢包;无线质量较差的情况下上行丢包现象较为严重,PDCP重传时间超时,数据包将被丢弃;
外场测试表明QCI 1 PDCP Discardtimer 配置与RTP丢包率及Jitter有密切关系,QCI 1 PDCP Discardtimer 配置越大,RTP丢包率越低,但Jitter也随之变大。

●MOS值与RTP丢包及Jitter关系都较大,目前正在进行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的对比验证。
1.9 MME专载保存功能(可选)
功能描述:在基站发起UE-lost原因值的上下文释放请求时,MME保持专载2s不释放,等待空口重建。
验证情况:已在某MME下成功验证了该功能。当时无线环境较差,UE发起RRC重建失败,通过MME专载QCI1保持功能使得在新发起的业务过程中,RRC重配中建立包括专载QCI1的3条DRB,不会发生掉话。(本次测试中专载保持时长约1.358s)
功能总结:
1)当无线环境较差时,UE发生RRC重建,若RRC重建成功,手机将不会掉话。
2)MME侧也可以在RRC重建失败后,通过MME专载QCI1保持功能使得在新发起的业务过程中,专载QCI1继续保持,也可使得手机不掉话。
3)此功能为爱立信MME非必选功能,建议打开。但是该功能不在集采目录,暂时无法采购。
1.10 专载释放与切换冲突,通话结束未收到专载释放掉话
[问题描述]:在拉网测试过程中,通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时手机发生切换,未收到EPS专载释放请求,1s后App统计掉话。
[问题分析]:经分析MME log,发现MME未收到PGW下发的delete bearer request消息。当X2切换触发SGW-initiated bearer modification procedure(完整信令是CCR-CCA),如果此时SIP挂机触发PCRF也发RAR给PGW,由于Gx链路时延等原因,使得RAR先于CCA到达PGW,根据协议规定,PGW会继续SGW-initiated bearer modification procedure而reject RAR (result code DIAMETER_OUT_OF_SPACE)。
[优化措施]:当前解决办法:
(1)缩短DRA时延配置。
(2)修改SAPC到DRA链路为主-备模式,保证CCA和RAR走同一路径和到达PGW的先后顺序。
[优化结果]:近期调整后的网格测试,暂时没有发现BYE200消息前后发生的切换没释放QCI 1专载的情况。
1.11 通话结束MME收到del bearer req,专载释放与切换冲突,基站未下发NAS
[问题描述]:通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时手机发生切换,EPS专载没有释放,1s后App统计掉话。
[问题分析]:主叫挂机后,MME收到del bearer req,下发Deactivate EPS bearer context Request给源eNB携带NAS释放专载,但同时源eNB触发X2切换,向MME响应ERAB release response (X2-Handover-Triggered),NAS消息未下发到手机。根据协议36.413 中8.6.2.4有描述当eNB在触发X2切换时,eNB将不传递NAS消息。
[优化措施]:属测试App统计问题,建议App加以剔除该问题。
2 案例分析
2.1 典型案例
案例1:LTE弱覆盖,eSRVCC切换不及时掉话
10:57:29.710基站下发异频异系统测量报告,包含2G频点及B2门限(LTE:-110,GERAN:-95)

10:57:38.479,主叫达到B2门限
10:57:42.109,主叫RSRP已恶化至-117dBm,SINR至-3,但终端仍没有上报B2事件
10:58:05.587,RTP包不能正常收发,10s后RTP inactivity定时器触发,会话中断,出现掉话:


解决建议:
①规范LTE频点配置,清理多余异频频点,缩短终端测量周期;
②终端芯片提高测量能力,尽快实现CDRX休眠期测量功能。
案例2:VoLTE单通现象
VoLTE单通现象分为两类:一是VoLTE打VoLTE单通,二是VoLTE拨打GSM单通。经分析,第一类主要是终端问题,第二类主要是网络问题。
注:红圈为RTP包抓包位置
案例3:eNodeB参数配置不合理,导致eSRVCC失败
问题现象:
终端发生eSRVCC时,在LTE向GSM切换过程中产生掉话。


问题分析:
终端可以正常收到测控消息,并上报测量报告,且掉话发生在向GSM切换过程中,是GSM或者和基站侧参数设置问题。
问题解决:
基站BsCAccess-ID项中的管理状态为Locked,设置有误。将该状态修改为Unlock后,对该站点进行重启后发现eSRVCC功能正常。
2.2 空口信令判断案例
案例1:RRC重建失败,无线网问题
现象:切换失败导致RRC释放,重建RRC未成功,重新进行RRC申请,QCI=1的承载未建立成功,导致掉话
分析:呼叫重建失败后,新小区重新申请RRC,未能建立VOLTE专载,导致掉话。该流程均由ENODEB控制实行。而切换失败的原因往往是无线环境问题、参数配置不合理、邻区漏配、非竞争随机接入异常等,均为无线网问题。
结论:切换失败与RRC重申请流程均与EUTRAN相关,因此认定为无线网问题。
案例2:基站异常导致双端无下行信令及RTP包断传,无线网问题
现象:主被叫VOLTE接通后,在同一小区同时发生缺失下行信令20秒,此后数秒发生终端上发bye request挂断。
分析:丢信令之前,主被叫双端处于同一小区,且RTP包双向传输正常。丢信令期间,终端测量信息完整,但在2秒后发生RTP包只有终端向网络单向传输,未再有任何网络下发的RTP包,高度怀疑基站临时故障导致。
结论:App显示丢信令,但通过进一步分析确认应为基站故障导致。无线网问题。
案例3: VOLTE接通下发生IMS注册掉话,IMS网络问题
现象: VOLTE接通后,被叫发生IMS注册且成功,此时主叫收到网络下发的bye request内含注册超时字样
分析:按照3GPP协议,终端应在3000秒上发注册,本次HUAWEISBC于3600秒才收到注册请求,此时IMS认为注册超时,对主叫下发了sip bye消息释放了。
但通过进一步确认,终端实际于600秒前已上发了注册消息(UDP),但此时恰好在G网下,未收到回复:
注:同样类型的掉话也有600秒前处于LTE网(TCP),而未收到OK或未鉴权回复的情况
结论:前10分钟的注册失败,导致了后续的IMS通话中释放,虽然终端前一次的失败处理机制可能存在问题,但仍然体现出IMS对通话中发生注册时直接释放会话的措施欠妥。
2.3 网元流程判断案例
案例1:被叫收到寻呼但未收到INVITE请求,核心网问题
现象:主叫上发了invite,被叫收到了寻呼且建立RRC成功,此时应收到下行的invite,但始终未收到。
分析:被叫响应寻呼并进行了RRC申请,表明MME已收到由SGW触发的数据业务请求,即sip invite消息应由IMS网元的SBC下发给了PGW、SGW。
①Sip invite消息由IMS网元SBC下发到被叫核心网网元PGW
②PGW转发给SGW,SGW通过S11触发MME进行寻呼被叫
③被叫被寻呼到,并完成RRC连接与建立默认承载所需RAB,接收数据
结论:收到寻呼消息表示sip invite数据包已经到达了LTE核心网,未能继续下发当前怀疑是sip数据在S/PGW异常丢失。
案例2:重配置消息释放DRB承载,无线网与核心网配合问题
现象:被叫上发sip183后,在激活EPS承载之前,终端上报了1条A3测报,激活EPS后,发生切换重配置消息中释放了QCI=1的DRB。
分析:起呼时MME进行激活EPS承载流程过程中,恰好发生S1切换时,由于EPS承载建立未完成,MME在切换准备阶段,对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载,导致VOLTE专载源小区完成的情况下,在目标小区被释放,切换完成后呼叫中断
①切换准备时,MME向目标小区发切换请求,RAB建立请求表只有2条,无QCI=1的专载
②目标小区收到MME的切换请求后,回复的切换确认消息里仅有2条RAB建立
③MME向源小区下发的切换命令消息中,只建立2条承载,导致ENODEB释放了QCI=1的VOLTE专载。
结论:切换与EPS激活流程碰撞,无线网与核心网配合问题。在进行激活EPS专载过程中,发生切换时,均会造成上述问题,目前还无较好的解决办法。
2.4 网络设备问题案例总结
案例1:中兴ENODEB异频重定向掉话,无线网问题
现象:主被叫VOLTE接通后,服务小区信号较差,但未配置异频邻区;通过重定向消息RRC connection release携带频点,由D频段重定向到F频段,但VOLTE呼叫不支撑重定向方式的RTP包接续,导致掉话。
设备:中兴ENODEB
分析:中兴设备为了防止邻区漏配情况下,影响用户在LTE数据业务下的感知质量,默认具备异频重定向功能,但未曾考虑对VOLTE呼叫的接续保持。
结论:完善邻区配置,在VOLTE呼叫区域考虑关闭中兴设备的异频重定向功能。
案例2:HUAWEI基站到卡特切换导致的RTP包传输中断问题,无线网问题
现象:主被叫接通状态下,在发生一次由HUAWEI设备到卡特设备的切换后,20秒后主被叫终端同时上发了bye request消息,网络侧回复bye(487 Request Terminated),后网络去激活了EPS承载,掉话。
设备:HUAWEIENODEB与卡特ENODEB
分析:PDCP SN SIZE长度有12bit和7bit,目前HUAWEI基站配置为12bit,贝尔配置为7bit,两个厂家配置数据不统一。HUAWEIenodeb设备具有自适应功能。
①在HUAWEI小区起呼时,切换到卡特小区时,卡特无自适应功能,PDCP SN不一致导致组包混乱。
②当在贝尔小区起呼时,切换到HUAWEI小区时,HUAWEIPDCP SN自适应为7bit,通话正常。
结论:临时解决方案:HUAWEIPDCP SN Size修改为7bit,进行拉网测试主叫呼叫56次,未出现终端主动上发bye的掉话。异常掉话及切换后单通问题基本解决
案例3:爱立信IMS网元CS域呼叫处理能力不足问题,IMS网络问题
现象:在做互通测试过程中,主叫VOLTE起呼后,被叫始终在TD下未收到寻呼消息,主叫收到网络侧下发trying后,马上收到网络下发的invtie 604(Does Not Exist Anywhere),呼叫失败。
设备:爱立信IMS
分析:空口信令仅能确认,被叫端处于TD网,发INVITE到MGCF,MGCF回复604 Does Not Exist Anywhere。该问题为爱立信IMS网元MGCF默认配置仅能同时容纳32个CS域呼叫,导致互通测试过程中,由于容量不足,造成大量连续未接通。
结论:爱立信IMS网元MGCF默认配置容量偏小,发生以上问题后,经过扩容已达可处理2、3G呼叫320个。
案例4:HUAWEIEPC修改EPS与切换碰撞,拒绝承载修改。核心网问题
现象:主叫VOLTE起呼后,收到网络回复trying,激活了EPS承载后,又进行了1次EPS承载的修改,此时主叫侧在发生了1次LTE的切换后,收到IMS网络下发的sip503消息,服务不可得。
设备:HUAWEIEPC
分析:某地在激活EPS完成后,仍需要进行2次EPS承载的修改,本次呼叫时第2次EPS的修改(空口信令不可见)恰好与切换同时发生,当IMS要求核心网PCRF需要对EPS承载进行修改时,由于切换具有更高的优先级,HUAWEIEPC拒绝了承载更新,而只实行切换,导致IMS下发sip 503消息中断呼叫
该市合适的CQI=1的EPS承载建立需要3个步骤:
①CQI=1的初始EPS承载建立,GBR=40kbps但TFT无IPV6地址
②修改GBR49kbps支撑高清语音并对TFT内的增加IPV6地址以及 UDP端口进行修改
③在现有TFT中再新建两个ptf。
结论:冗余的EPS承载修改TFT,一方面导致了呼叫建立时延长;同时增加了与切换发生冲突的几率;HUAWEIEPC在切换与修改EPS承载冲突时,不具备同时处理或排队处理的能力,导致直接以“资源临时不可得”拒绝了承载更新。一方面建议降低EPS承载修改次数,减少切换碰撞几率与时延;另一方面建议HUAWEIEPC进行升级。

举报本楼

本帖有 3 个回帖,您需要登录后才能浏览 登录 | 注册
您需要登录后才可以回帖 登录 | 注册 |

手机版|C114 ( 沪ICP备12002291号-1 )|联系大家 |网站地图  

GMT+8, 2024-11-27 11:47 , Processed in 0.561166 second(s), 15 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部
XML 地图 | Sitemap 地图