VOLTE案例分析Word文档下载推荐.docx
《VOLTE案例分析Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《VOLTE案例分析Word文档下载推荐.docx(29页珍藏版)》请在冰豆网上搜索。
![VOLTE案例分析Word文档下载推荐.docx](https://file1.bdocx.com/fileroot1/2022-10/7/08acd238-1f7c-424e-9601-3c617783f4a5/08acd238-1f7c-424e-9601-3c617783f4a51.gif)
UE在无线信道较差的情况下,SIP信令发送或接收不完整或者无法及时传递,导致IMS相关定时器超时而发起会话cancel。
经过分析,由于QCI5的pdcp丢弃时长过小,在无线覆盖较差的地方,上行时延会变大,容易导致QCI5信令丢包。
QCI5PDCPDiscardTimer由300ms修改为无穷大
优化效果:
VoLTE无线接通率提升明显
1.4SBC传输协议TCP重传次数优化
背景:
被叫从2G返回4G后,主叫起呼,被叫首先bye消息,紧接着接连收到多条上一次呼叫的invite,被叫回复bye481invite486invite580,呼叫失败。
爱立信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,仍需完善现有功控方式。
修改后,PUSCHTxPower(10dbm以上)占比由40%下降到30%左右。
1.8RTP丢包率优化
测试发现,XX区域RTP丢包率偏高,个别网格甚至达到2%以上。
在无线质量较好的情况下基本无丢包;
无线质量较差的情况下上行丢包现象较为严重,PDCP重传时间超时,数据包将被丢弃;
外场测试表明QCI1PDCPDiscardtimer配置与RTP丢包率及Jitter有密切关系,QCI1PDCPDiscardtimer配置越大,RTP丢包率越低,但Jitter也随之变大。
●MOS值与RTP丢包及Jitter关系都较大,目前正在进行100ms/300ms/500ms/750ms/1500ms/infinity完整的对比验证。
1.9MME专载保存功能(可选)
功能描述:
在基站发起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后软件统计掉话。
[问题分析]:
经分析MMElog,发现MME未收到PGW下发的deletebearerrequest消息。
当X2切换触发SGW-initiatedbearermodificationprocedure(完整信令是CCR-CCA),如果此时SIP挂机触发PCRF也发RAR给PGW,由于Gx链路时延等原因,使得RAR先于CCA到达PGW,根据协议规定,PGW会继续SGW-initiatedbearermodificationprocedure而rejectRAR(resultcodeDIAMETER_OUT_OF_SPACE)。
[优化措施]:
当前解决办法:
(1)缩短DRA时延配置。
(2)修改SAPC到DRA链路为主-备模式,保证CCA和RAR走同一路径和到达PGW的先后顺序。
[优化结果]:
近期调整后的网格测试,暂时没有发现BYE200消息前后发生的切换没释放QCI1专载的情况。
1.11通话结束MME收到delbearerreq,专载释放与切换冲突,基站未下发NAS
通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时手机发生切换,EPS专载没有释放,1s后软件统计掉话。
主叫挂机后,MME收到delbearerreq,下发DeactivateEPSbearercontextRequest给源eNB携带NAS释放专载,但同时源eNB触发X2切换,向MME响应ERABreleaseresponse(X2-Handover-Triggered),NAS消息未下发到手机。
根据协议36.413中8.6.2.4有描述当eNB在触发X2切换时,eNB将不传递NAS消息。
属测试软件统计问题,建议软件加以剔除该问题。
2案例分析
2.1典型案例
案例1:
LTE弱覆盖,eSRVCC切换不及时掉话
10:
57:
29.710基站下发异频异系统测量报告,包含2G频点及B2门限(LTE:
-110,GERAN:
-95)
38.479,主叫达到B2门限
42.109,主叫RSRP已恶化至-117dBm,SINR至-3,但终端仍没有上报B2事件
58:
05.587,RTP包不能正常收发,10s后RTPinactivity定时器触发,会话中断,出现掉话:
解决建议:
①规范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空口信令判断案例
RRC重建失败,无线网问题
切换失败导致RRC释放,重建RRC未成功,重新进行RRC申请,QCI=1的承载未建立成功,导致掉话
分析:
呼叫重建失败后,新小区重新申请RRC,未能建立VOLTE专载,导致掉话。
该流程均由ENODEB控制执行。
而切换失败的原因往往是无线环境问题、参数配置不合理、邻区漏配、非竞争随机接入异常等,均为无线网问题。
结论:
切换失败与RRC重申请流程均与EUTRAN相关,因此认定为无线网问题。
基站异常导致双端无下行信令及RTP包断传,无线网问题
主被叫VOLTE接通后,在同一小区同时发生缺失下行信令20秒,此后数秒发生终端上发byerequest挂断。
丢信令之前,主被叫双端处于同一小区,且RTP包双向传输正常。
丢信令期间,终端测量信息完整,但在2秒后发生RTP包只有终端向网络单向传输,未再有任何网络下发的RTP包,高度怀疑基站临时故障导致。
软件显示丢信令,但通过进一步分析确认应为基站故障导致。
无线网问题。
VOLTE接通下发生IMS注册掉话,IMS网络问题
VOLTE接通后,被叫发生IMS注册且成功,此时主叫收到网络下发的byerequest内含注册超时字样
按照3GPP协议,终端应在3000秒上发注册,本次华为SBC于3600秒才收到注册请求,此时IMS认为注册超时,对主叫下发了sipbye消息释放了。
但通过进一步确认,终端实际于600秒前已上发了注册消息(UDP),但此时恰好在G网下,未收到回复:
同样类型的掉话也有600秒前处于LTE网(TCP),而未收到OK或未鉴权回复的情况
前10分钟的注册失败,导致了后续的IMS通话中释放,虽然终端前一次的失败处理机制可能存在问题,但仍然体现出IMS对通话中发生注册时直接释放会话的措施欠妥。
2.3网元流程判断案例
被叫收到寻呼但未收到INVITE请求,核心网问题
主叫上发了invite,被叫收到了寻呼且建立RRC成功,此时应收到下行的invite,但始终未收到。
被叫响应寻呼并进行了RRC申请,表明MME已收到由SGW触发的数据业务请求,即sipinvite消息应由IMS网元的SBC下发给了PGW、SGW。
①Sipinvite消息由IMS网元SBC下发到被叫核心网网元PGW
②PGW转发给SGW,SGW通过S11触发MME进行寻呼被叫
③被叫被寻呼到,并完成RRC连接与建立默认承载所