广州Volte指标提升过程经验总结.docx
- 文档编号:30180292
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:36
- 大小:5MB
广州Volte指标提升过程经验总结.docx
《广州Volte指标提升过程经验总结.docx》由会员分享,可在线阅读,更多相关《广州Volte指标提升过程经验总结.docx(36页珍藏版)》请在冰豆网上搜索。
广州Volte指标提升过程经验总结
1项目概述
1.1项目背景
VoLTE是基于IMS网络承载语音业务。
广州TDD-LTE网络9000多个站eNodeB600P04版本升级完后,能正常支持Volte功能;2014年广东移动LTE网优专项子课题之一《Volte无线网管指标研究》,主要研究Volte语音接通率低、掉话率高问题定位和解决提升方法,并对提升用户感知方法进行总结,作为后续广州移动全网开启Volte试商用优化参考思路。
1.2VOLTE原理说明
VoIP是VoiceOverInternetProtocol的简称,意为在Internet上传输语音。
VoIP简而言之就是将模拟声音信号数字化,以数据封包的型式在IP数据网络上做实时传递。
VoLTE指的是基于IMS网络承载语音业务。
由于语音业务具备的特性(周期性、激活期、静默期、小数据量),eNodeB针对语音承载可以采用SPS、ROHC技术,以发挥最大的网络性能;当UE处于远点时采用TTIBundling来提升边缘覆盖。
VoLTE的架构主要是从功能整体出发,描绘出引入VoLTE后,各个功能模块的分工。
呼叫流程
UE在IDLE下呼叫,主叫UE先触发servicerequest流程,完后发起invite消息;核心网先给被叫UE发送paging消息,被叫UE回复servicerequest流程,建立链接后,核心网才能把invite转发给被叫UE。
下面描述在连接下的呼叫流程图,UE1呼叫UE2:
挂机流程
主叫UE1发起的挂机流程:
1.3版本说明
EMS:
V12.13.51P12版本;
eNB:
V3.30.601版本。
1.4参数配置情况
参数中文名
参数所在表
统一规范值
备注
基于语音的测量配置开关
管理网元—无线参数—TD-LTE—E-UTRAN TDD小区—测量参数
打开
A2(32)事件判决的RSRP门限
管理网元—无线参数—TD-LTE—测量参数配置—UE系统内测量参数
-104
语音与数据A2事件是相互独立的,语音A2事件是测量索引号【32】,数据A2事件测量索引号【30】;修改语音A2事件不影响数据业务。
另外,因为这次参数调整无修改A1,所以修改A2时候需要检查A1的值是否都大于-106(A2),若不是,则把A2设置成比A1小4个db。
例如,A1为-106,则A2设置成-110。
B2(1012)事件RSRP测量时EUTRAN系统服务小区判决的绝对门限
管理网元—无线参数—TD-LTE—测量参数配置—UE系统间测量参数
-110
语音与数据B2事件是相互独立的,语音B2事件测量索引号【1012】,数据业务测量索引号【1010】,修改语音B2事件不影响数据业务。
PS切换能力
管理网元—无线参数—TD-LTE—邻接小区配置—GERAN邻接小区
是
异系统GERAN邻区的DTM能力
管理网元—无线参数—TD-LTE—邻接小区配置—GERAN邻接小区
支持DTM不支持DTMHO
异系统GERAN邻区的VoIP能力
管理网元—无线参数—TD-LTE—邻接小区配置—GERAN邻接小区
不支持
服务小区与系统间邻区关系
管理网元—无线参数—TD-LTE—邻接关系配置—GERAN邻接关系
相邻
支持切换
管理网元—无线参数—TD-LTE—邻接关系配置—GERAN邻接关系
支持
ULSRVCC功能开关
管理网元—无线参数—TD-LTE—无线业务配置—全局业务开关
关闭[0]
是否支持ROHC格式Profile0x0001
管理网元—无线参数—TD-LTE—无线业务配置—应用PDCP参数
是,QCI=2,
RLC承载类型
管理网元—无线参数—TD-LTE—Qos配置—Qos业务类型
非确认模式
GERAN载频数目
管理网元—无线参数—TD-LTE—E-UTRANTDD小区—测量参数
1
频间测量和系统间测量是否同时下发
管理网元—无线参数—TD-LTE—E-UTRANTDD小区—测量参数
关闭[0]
调度算法
管理网元—无线参数—TD-LTE—E-UTRANTDD小区—EMLP
非SPS[2]
1.5测试设备
测试软件使用Pioneer9.5,终端使用HTCM8t手机(高通芯片)。
测试软件使用CDS7.1/鼎利9.4,终端HTCM8t(高通芯片)进行前后对比。
测试软件
CDS7.1/鼎利9.5
终端名称
HTCM8t手机
终端类别
四类
2未接通问题分析
未接通问题的主要包括无线参数问题(异频重定向、异系统重定向)、无线覆盖问题、专载异常问题(包括切换过程中专载被MME释放和终端未收到专载建立请求)、Paging问题、esrvcc问题(Alerting中eSRVCC导致的未接通、Alerting前eSRVCC导致的未接通)、设备故障问题、核心网问题(IMS信令异常、INVITE500及INVITE580)等,其中:
1.无线参数问题、无线覆盖问题属于无线问题,已经通过关闭系统内异频重定向、核查添加4到2G邻区以及区域优化等手段解决。
2.专载异常问题:
1、切换过程中专载被MME释放类问题:
a、已经通过修改QCI5信令优先级,提高SRB2的优先级来优先传送NAS信息,解决切换过程中专载被释放问题;b、开启X2切换功能,S1切换需要MME参与,开启X2后切换过程不需要MME控制,降低该问题发生的概率;c、R5o小版本:
基站等待NAS消息,专载建立过程中,基站收到MR测量报告,将缓存200ms,等NAS消息上报后再发起切换控制,可以降低该问题发生的概率,目前版本正在试用阶段。
2、终端未收到专载建立请求:
需要结合基站侧信令分,a基站是否收到专载建立请求,基站收到专载建立请求下发给终端但终端未收到专载建立请求,原因可能是下行链路太差导致终端无法收到;b核心网未下发专载建立请求,联系核心网排查未下发专载建立请求原因。
3.Paging问题:
被叫无法响应寻呼导致的未接通的原因包括终端自身问题、无线问题及核心网问题,通过排查终端故障,优化覆盖及联系核心网协助解决。
4.ESRVCC问题:
1、Alerting前eSRVCC导致的未接通:
主被叫流程还未进行到振铃,此时主叫或被叫达到了eSRVCC切换条件并进行切换,切换后会话中断,未能接通。
2、Alerting中eSRVCC导致的未接通:
被叫已振铃,此时主叫或被叫达到了eSRVCC切换条件并进行切换,切换后会话中断,未能接通。
由于IMS及核心网功能或版本问题,在呼叫振铃后ACK消息前发生ESRVCC会导致未接通,上述两类问题需优化4G网络覆盖,尽量让UE驻留在LTE小区内,根据无线环境实际情况调整B2异系统门限,减少终端切换至2G造成未接通的几率。
5.核心网问题:
属于端对端问题分类,包括IMS信令异常、INVITE500及580等SIP流异常造成的未接通。
UE在无线信道较差的情况下,SIP信令在传递的过程中,发送或接收的数据不完整或者无法及时传递,导致IMS相关定时器超时而发起会话cancal。
经过分析,可能是由于QCI5的pdchdiscardtimer过小,在无线覆盖较差的地方,上行时延会变大,容易导致QCI5信令丢包,现在已经修改全网CQI5的discartimer由300ms修改为无穷大,修改后很少发生SIP信令丢失的问题,问题基本解决。
2.1切换过程中专载被MME释放导致未接通
【问题描述】
主叫或被叫在呼叫时的专载建立过程中,MME若未收到UE反馈专载建立完成的消息,此时发生切换,MME将在目标小区发起专载释放的请求,导致未接通。
【问题分析】
主叫发起INVITE请求后,收到网络转发的100trying消息,接下来进行专载建立与激活流程,在收到网络下发的专载建立请求之前,主叫上报了A3测量报告,随后进行专载建立流程,在激活专载并上报NAS确认消息后,主叫收到网络下发的切换重配置命令,在重切换配置消息中携带了QCI1专载释放命令,随后主叫上报cancel取消本次通话。
【问题定位】
由于终端上报A3时间在上报NAS确认消息之前,基站侧在收到A3测量报告后向MME发起切换请求,在切换过程中MME发给目标小区的handoverRequest消息中e_RABToBeSetupListHOReq少了QCI1的承载,所以ReleaseQCI1的承载。
【解决措施】
目前主要通过修改QCI5优先级,提高SRB2的优先级来优先传送NAS信息,解决切换过程中专载被释放问题。
2.2终端未收到专载建立请求导致未接通
【问题描述】
主叫或被叫在呼叫过程中,未收到系统下发的专载建立请求导致未接通。
【问题分析】
上次正常通话结束后,本次通话主叫发送trying100消息后,核心网下发专业承载请求后主叫开始建立和激活专载流程。
被叫在上报183后,正常流程应该是由核心网下发专业承载建立请求后被叫开始建立专载过程,但实际上被叫一直未收到核心网下发的QCI1建立请求,主叫在上报PRACK后收到网络下发的481Calllegtransactiondoesnotexist消息,随后主叫上报cancel消息取消本次通话。
【问题定位】
终端未收到专载建立请求原因可能有:
1、无线环境太差,基站转发了核心网下发的专载建立请求但终端未收到;2、核心网未下发专载建立请求。
【解决措施】
需结合基站测CTS信令查看核心网是否下发专载建立请求消息,如下发了专载建立请求但终端未收到需要检查下行链路是否太差导致,需要优化下行覆盖。
核心网问题导致核心网未下发专载建立请求,需要核心网侧查找未下发专载建立请求原因。
2.3Alerting中eSRVCC导致的未接通设备故障问题
【问题描述】
被叫已振铃,此时主叫或被叫达到了eSRVCC切换条件并进行切换,切换后会话中断,未能接通。
【问题分析】
主被叫呼叫流程正常进行至振铃阶段,被叫在上报180ringing后,收到网络了转发的ACK确认消息前,也就是振铃后接通通话前,被叫上报B2测量报告(BCCH67BSIC2BCCHLevel-86dBm),核查上报MR已满足B2判决门限,ENB下发eSRVCC命令指示UE切换至2G网络,13:
55:
45.956上发HandoverComplete,13:
55:
46.156收到网络下发Disconnect释放原因:
(50)Requestedfacilitynotsubscribed,导致未接通。
【问题定位】
对于Alerting中或Alerting前eSRVCC导致的未接通,主要是由于IMS及核心网功能或版本问题,在呼叫流程进行至ACK之前发生ESRVCC后都会造成未接通情况。
【解决措施】
需要联系IMS和核心网侧研发解决这类问题,无线侧优化手段有提升该路段覆盖,合理设置B2门限,使终端尽量占用LTE网络进行通话。
2.4设备故障问题导致的未接通
【问题描述】
会话流程正常接续,终端上报Cancel,导致会话未接通
【问题分析】
1、主叫在14:
53:
03.998起呼,信令流程正常,且被叫上发Ringing180,主叫收到网络侧转发的Ringing180,主被叫都已经振铃。
但是主叫突然在14:
53:
06.510上发Cancel,被叫也收到网络侧转发的Cancel,会话接续停止,导致未接通。
【问题定位】
主被叫会话流程正常,无线环境良好,信令转发正常。
主叫上报Cancel,导致会话未接通,定位为终端问题
【解决措施】
测试前调试终端设备,确认无问题或者更换终端测试再查看结果.
2.5580PreconditionFailure导致未接通
【问题描述】
测试和分析中,有时会遇到PreconditionFailure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580PreconditionFailure消息,随后呼叫中止,出现未接通事件。
【问题分析】
1、呼叫过程中,被叫发送Ringing180后,收到网络下发的专载去激活命令,QCI1被释放,被叫随后上报580PreconditionFailure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通。
2、从信令中可以看到,被叫回复Ringing180且主叫也已经收到Ringing180,被叫随后收到网络侧下发的RRC重配,携带有QCI1被释放的信息,被叫去激活专有承载。
由于专载已被释放,业务资源已不存在,所以被叫上发580PreconditionFailure失败消息。
主叫收到网络侧下发的580,接续被中止,导致了会话未接通。
3、从MME下发到NodeB的E-RABRELEASECOMMAND,原因上看是Nas层nomal_release,导致专载QCI1被释放。
4、专载QCI1被释放,去激活后,被叫发送INVITE580,主叫收到网络侧转发的INVITE580,会话流程中断,导致未接通。
【问题定位】
在正常的会话流程中,由于MME下发E-RABRELEASECOMMAND,使得QCI1被释放,导致未接通。
【解决措施】
需要核心网查看MME在什么情况下会下发E-RABRELEASECOMMAND。
2.6ServerInternalError500导致未接通
【问题描述】
在测试和分析过程中有时候会遇到ServerInternalError500导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的ServerInternalError500消息,随后呼叫中止,出现未接通事件。
【问题分析】
1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE200,随后被叫发送Ringing180,主叫同时收到UPDATE200和Ringing180。
按照正常的信令流程应该是先收到UPDATE200,再收到Ringing180。
2、然后主叫收到网络侧下发的INVITEServerInternalError500.主叫专载被释放,去激活,导致会话未接通。
【问题定位】
主叫收到网络侧下发的INVITE500,然后网络侧又下发RRC重配,释放掉QCI1,然后去激活,会话流程终止,导致未接通
【解决措施】
需要核心网确认,为什么会下发INVITE500,什么情况下会导致网络侧下发INVITE500,随后的专载释放是否由INVITE500导致的
3掉话问题分析
掉话问题的主要包括无线参数问题(异频重定向和异系统重定向)、无线覆盖问题、TM3\8切换问题、ESRVCC至2G后掉话、eSRVCC失败、设备故障、核心网问题等,其中:
1.无线参数问题:
1、异频重定向掉话,通过DV表关闭系统内重定向开关,解决未知PCI的重定向(没配置邻区),同时加强网优工作,避免漏配邻区发生。
2、异系统重定向掉话:
1、终端上报B2事件后未发生esrvcc切换而是直接下发rrcconnectionrelease重定向至2G导致掉话,该类问题主要是4到2G邻区参数配置错误或者未配置邻区关系导致重定向掉话,通过核查4到2G邻区参数或添加2G邻区解决。
2、终端无线环境逐渐恶化后达到A2盲重定向门限后进行异系统盲重定向导致掉话,导致该类问题发生可能原因有:
a)1、4G站点未配置2G邻区,终端是根据测量配置里配置的频点来测量周边的2G小区的,如果4G站点未配置2G小区邻区,导致终端无法测量周边2G小区,若周边无最优接续小区可占用,终端在达到A2盲重定向门限进行盲重定向导致掉话。
b)B2门限设置不合理,可能B2-1本系统门限设置太高,导致UE在达到门限后还未来得及异系统测量,无线环境便恶化至A2忙重定向门限后启动异系统盲重定向导致掉话;
c)B2-2异系统门限设置太高,导致该路段无满足条件的2G信号可以测量上报,最终终端无线太差达到A2盲重定向门限进行盲重定向导致掉话;
d)严重弱覆盖区域,LTE和GSM信号都非常差,周边无最有接续小区,终端达到A2盲重定向门限进行盲重定向导致掉话。
以上问题可以通过添加4到2G邻区,设置合理的B2门限以及优化4G网络覆盖解决异系统重定向导致的掉话。
2.无线覆盖问题导致的掉话,主要是RSRP/SINR过差导致无线链路异常释放,无线覆盖优化包括两方面:
1、通过SINR优化目前主要优化方法通过减少道路的重叠覆盖干扰,降低模三干扰,消除外部干扰等方式;2、通过梳理小区的切换关系,核查小区的告警信息及处理故障小区,通过调整天馈、功率或增加基站等措施优化覆盖。
3.TM3\8切换问题:
由于A2测量上报后发送的测量控制消息和TM3/8模式切换的重配消息时间间隔太近,导致基站控制面提前通知底层TM模式切换程序,切换到下行发送模式,后果就是TM3/8模式切换的重配消息是使用TM8模式发送的,而此时UE还工作在TM3状态,导致UE无法正确解调模式切换消息,出现TM8的重配无法下发,用户面上报SRB1的RLC的ERRORIND导致释放而掉话,该类问题已经在新版本解决,目前规避措施是改为强制TM3模式。
4.ESRVCC至2G后掉话:
终端上报B2后收到基站的mobility命令,并回复RRHANDOVERCOMPLETE正常切换至2G后,在2G网络发生掉话,需要分析GSM掉话原因。
5.eSRVCC失败:
eSRVCC失败后恢复4G通话失败,需要查看2G核心网是否支持ESRVCC功能、排除2G及4G无线原因导致esrvcc失败无法回复4G通话。
6.核心网问题:
:
核心网给主、被叫发送BYE,通话异常结束,或通话结束后核心网未正常给主叫、被叫专载释放命令。
3.1异频重定向导致掉话
【问题描述】
主被叫呼叫流程正常,发现主叫或被叫在正常通话中,发生异频重定向,导致RRC空口释放,进而导致掉话。
【问题分析】
具体如下图所示:
当会话接续的过程中,当达到切换门限(异频A3),终端上报满足切换的小区,但是,该小区未配置为邻区,就会发生异频重定向,重定向到上报的小区,此时,RRC空口释放,导致未接通。
【解决措施】
添加异频邻区,并关闭系统内异频重定向。
3.2异系统重定向导致掉话1
【问题描述】
主被叫呼叫流程正常,发现主叫或被叫在正常通话中,发生异频重定向,导致RRC空口释放,进而导致掉话。
【问题分析】
主被叫正常通话过程中,被叫占用ECI=1683632,RSRP=-114dbm,达到满足esrcvv切换的门限并且已经上报了B2(BCCH=542,BSIC=22)测量报告,正常情况下ENB会下发MobilityfromEutrancommand消息指示终端进行esrvcc切换至2G,但实际上ENB直接下发RRCconnectionrelease指示终端进行异系统重定向至2G,RRC空口释放导致掉话。
被叫重定向至2G后占用的GSM小区为BCCH=542,BSIC=22,CI=49923,LAC=9728。
【问题定位】
造成此次异系统重定向原因可能为LTE(ECI=1683632)小区4到2邻区配置错误,或者未配置邻区关系导致。
查看网管邻区配置发现LTE站点外部小区中存在2G邻区关系,邻区关系中却无对应2G邻区关系。
邻区中2G小区LAC=9728,CI=49923对应的4G站点为1683631。
【解决措施】
添加LTEECI=1683632与GSM(BCCH=542,BSIC=22.CI=49923,LAC=9728)的4-2邻区关系。
3.3异系统重定向导致掉话2
【问题描述】
主被叫呼叫流程正常,发现主叫或被叫在正常通话中,发生异频重定向,导致RRC空口释放,进而导致掉话。
【问题分析】
主被叫正常通话过程中,随着终端所占用的小区rsrp逐渐恶化而周边无最优接续小区可以占用,当RSRP低于A2异系统忙重定向门限时(RSRP<-122dbm),在上报A2测量报告后,ENB下发rrcconnectionrelease消息指示终端进行异系统盲重定向至2G,RRC空口释放导致掉话。
【问题定位】
造成此类问题的原因在于问题所在区域2/4G无线环境较差,系统内终端无最优小区可以占用,系统外无可满足测量上报的的异系统小区,导致UE无法及时切换至最优小区或esrvcc至2G小区进行通话,最终达到盲重定向门限进行异系统重定向,RRC空口释放导致掉话。
【解决措施】
优化问题路段4G网络覆盖情况,根据现场情况合理设置B2门限。
3.4无线覆盖问题导致掉话
【问题描述】
主叫拨打被叫的时候,由于现场环境高架桥底,现场环境差,RRC重建立拒绝后终端上发BYE消息后掉话
【问题分析】
具体如下图所示:
主叫拨打被叫的时候,根本原因是无线环境差,主叫RSRP为-105dbm,SINR为2.1,RRC重建立拒绝后终端上发BYE消息后掉话。
【解决措施】
对判断为无线弱覆盖的区域,需要进行邻区配置优化及工程优化。
3.5TM3\8切换问题导致掉话
【问题描述】
从前台信令看掉话流程,终端的模式为TM3,然后上发A2测量,然后终端收到异频测量控制的重配消息,发送完成后下行链路失步,之后发起重建后掉话。
此过程中,无线环境在RSRP-100,SINR3左右。
从后台信令分析,基站侧收到终端上发的A2,然后下发测量重配消息,紧接着发送TM8模式切换的重配消息,出现TM8的重配无法下发,用户面上报SRB1的RLC的ERRORIND导致释放而掉话
【问题分析】
1、从终端侧信令分析来看:
12:
09:
14秒的UE的发送模式配置为TM3模式
12:
09:
16秒,UE上发A2测量报告,然后收到异频测量控制消息,之后下行失步,在12:
09:
26秒发起重建请求。
2、从基站侧信令来看:
12:
09:
18收到UE上报的A2测量事件,然后发送异频切换测控消息,并正常收到完成消息。
12:
09:
18.389,基站下发TM8模式转换的重配消息,如下图:
该消息一直未发出,在12:
09:
25.089秒出现错误的标示,原因是该重配未下发,达到最大重传次数。
【问题定位】:
经过分析,该问题是由于A2测量上报后发送的测量控制消息和TM3/8模式切换的重配消息时间间隔太近,导致基站控制面提前通知底层TM模式切换程序,切换到下行发送模式,后果就是TM3/8模式切换的重配消息是使用TM8模式发送的,而此时UE还工作在TM3状态,导致UE无法正确解调模式切换消息。
【解决措施】:
该问题已经在新版本解决,目前规避措施是改为强制TM3模式。
3.6eSRVCC至2G后掉话
【问题描述】
主被叫正常通话后,主叫或被叫成功ESRVCC至2G后,在2G出现掉话。
【问题分析】
主被叫通话正常后,主叫在上报B2测量报告后,随后收到系统下发的MobilityfromEutrancommand消息指示终端进行esrvcc切换至2G,主叫回复handovercomplete后随后占用2G进行通话。
随后在占用2G通话后,主叫所占用的2G信号逐渐变差,邻区存在较强信号可以接入,终端不断上报测量报告但未发生切换,最终无线环境逐渐恶化出现连续7级质差,网络下发RRchannelrelease释放连接导致掉话。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 广州 Volte 指标 提升 过程 经验总结