2023年VOLTE专项案例库

优化案例提供的案例必须通过无线信令分析，每个案例必须与投标方所从事的工程关联，提供的案例需指明所从事工程合同名称、合同编号，及相关合同关键页复印件，同时案例要求有详细的分析过程、指出问题所在、提出解决方案、并有实施效果前后比照等要素，即为一个合格的案例.附表2-优化案例提供的案例必须通过无线信令分析，每个案例必须与投标方所从事的工程关联，提供的案例需指明所从事工程合同名称、合同编号，及相关合同关键页复印件，同时案例要求有详细的分析过程、指出问题所在、提出解决方案、并有实施效果前后比照等要素，即为一个合格的案例.格式自拟优化案例目合同名称、合同编号，及相关合同关键页复印件序号案例名称合同名称合同编号16.2.1.北京移动某区域CSFB提升优化中国移动北京公司2023-2023年五环外无线网络日常优化效劳合同〔第一比选包〕CMBJ-2023-00004934-CG-0000091526.2.2.MGCF参数配置问题导致未接通中国移动通信集团内蒙古2023年日常优化效劳框架合同〔乌海业务区〕OPER2023-02436.2.3.UE瞬间脱网案例分析中国移动北京公司2023-2023年五环外无线网络日常优化效劳合同〔第一比选包〕CMBJ-2023-00004934-CG-0000091546.2.4.VOLTE参数设置导致eSRVCC无法切换中国移动通信集团内蒙古2023年日常优化效劳框架合同〔乌海业务区〕OPER2023-02456.2.5.Volte功能特性设置导致被叫未接通中国移动北京公司2023-2023年五环外无线网络日常优化效劳合同〔第一比选包〕CMBJ-2023-00004934-CG-0000091566.2.6.智能网导致主叫未接通、被叫单通20S掉话问题陕西移动2023年第三方根底优化效劳框架合同〔电旗〕OPER2023-03476.2.7.目标小区故障导致SRVCC切换失败2023年河北移动无线网络根底支撑效劳采购合同WLWH2023030286.2.8.二次注册IP端口号不一致导致注册失败2023年河北移动无线网络根底支撑效劳采购合同WLWH2023030296.2.9.VOLTE用户前转优化2023年河北移动无线网络根底支撑效劳采购合同WLWH20230302106.2.10.E-Nodeb参数设置错误导致接通时延较大湖南移动日常协优效劳合同〔主用合同-北京电旗〕CMHNBBCG2023-1-0067116.2.11.核心网入Pool导致切换成功率下降陕西移动2023年第三方根底优化效劳框架合同〔北京电旗〕SN(2023)0552126.2.12.超级小区切换入失败问题优化提升中国移动北京公司2023-2023年五环外无线网络日常优化效劳合同〔第一比选包〕CMBJ-2023-00004934-CG-00000915136.2.13.CSFB提升优化2023年河北移动无线网络根底支撑效劳采购合同WLWH20230302146.2.14.北京LTE驻留比优化中国移动北京公司2023-2023年五环外无线网络日常优化效劳合同〔第一比选包〕CMBJ-2023-00004934-CG-00000915北京移动某区域CSFB提升优化问题描述LTE优化人员测试发现某地区同时出现CSFB通话结束后2G会回到4G室分频点后再重选到4G宏站频点，该问题较为异常，目前已经对该问题进行信令侧分析。问题分析正常信令：异常信令：异常信令正常信令当UE占用GSM网络进行语音通话结束后，UE收到EnodeB下发的SIB1系统消息后向EnodeB发送TAU请求，并发起RRC连接请求，随后EnodeB下发RRC建立链路指令，UE响应并发送RRC建立链路完成。正常情况下UE会使用与EnodeB建立完成的链路完成TAU过程。但上图异常信令中RRC建立链路完成之后UE却第二次收到了EnodeB下发RRC建立链路指令。随后UE第一次上报Cell_List，上报情况如下：异常占用频点正常占用频点UE从GSM返回LTE后第一次上报Cell_List室分频点变成了主效劳小区，而宏站频点变成了邻区，其中室分小区RSRP=-113dBm，宏站小区RSRP=-95dBm，正常情况下UE会占用RSRP最强的小区。实施方案7月29日对室分问题连同G网人员一同进行处理，选取凯莱酒店室分场景进行测试，对G网小区40261、20421、30011、30012进行FR功能关闭后测试：处理前占用4G宏站站点拨测回落G网频点占用G网小区回退4G站点CSFB回落时延备注福斯德-ZLH_251240261钟鼓楼办事处-ZLW_112.57s主叫福斯德-ZLH_251240261信合大楼-ZLW_110.707s主叫福斯德-ZLH_26430012钟鼓楼办事处-ZLW_14.61s被叫处理后福斯德-ZLH_251240261财贸广场-ZLH_38.534s主叫福斯德-ZLH_26430012福斯德-ZLH_29.556s主叫福斯德-ZLH_26430012福斯德-ZLH_23.590s被叫调整措施UE占用宏站拨打〔09:44:06〕通话结束后G网占用频点512链路释放：UE占用频点512回退且首先回退到室分信号〔钟鼓楼办事处-ZLW_1〕：CSFB回落时延〔12.57s〕：UE占用宏站拨打〔09:44:50〕通话结束后G网占用频点512链路释放：UE占用频点512回退且首先回退到室分信号〔信合大楼-ZLW_1〕：CSFB回落时延〔10.707s〕：UE占用宏站接听〔10:14:47〕通话结束后G网占用频点64链路释放：UE占用频点64回退且首先回退到室分信号〔钟鼓楼办事处-ZLW_1〕：CSFB回落时延〔4.61s〕：效果比照UE占用宏站拨测〔14:30:16〕：通话结束后G网占用频点512链路释放：UE占用频点512回退且回退到宏站信号〔财贸广场-ZLH_3〕：CSFB回落时延〔8.534s〕：UE占用宏站拨测〔10:38:36〕：通话结束后G网占用频点64链路释放：UE占用频点64回退且回退到宏站信号〔福斯德-ZLH_2〕：CSFB回落时延〔9.556s〕：UE占用宏站接听〔10:38:42〕：通话结束后G网占用频点64链路释放：UE占用频点64回退且回退到宏站信号〔福斯德-ZLH_2〕：CSFB回落时延〔3.590s〕：G网FR开关翻开时，UE在附近有室分信号的情况下，占用宏站拨测通话结束后首先回落室分信号再切换到宏站信号，而G网FR开关关闭后得该问题得到解决。1、问题处理前CSFB回落时延〔12.57s〕、〔10.707s〕、〔4.61s〕，处理后时延〔8.534s〕、〔9.556s〕、〔3.590s〕通过问题处理前后比照，主被叫CSFB回落时延都有明显改善。、2、后续需要G网优化人员对该问题全网性处理。案例合同关键页MGCF参数配置问题导致未接通现象描述车辆乌海大学校园内行驶，被叫UE占用海勃湾奥林匹克中心-NLHF-2〔PCI=141、RSRP=-87.43dbm、SINR=22.8〕，09:34:49.683奥体中心附近出现未接通。问题分析从LOG分析发现主被叫信令流程，在MO发送完IMS_SIP_INVITE->Request消息后，MT正常接收网络侧转发的IMS_SIP_INVITE->Request，并上发IMS_SIP_INVITE->Trying100消息确认请求处理成功。在上发IMS_SIP_INVITE183会话消息后，网络侧下发LTENAS-->DeactivateEPSbearercontextrequest，释放QCI1专用承载，释放原因为ESMCause=(36)Regulardeactivation。随后网络侧下发LTERRC-->RRCConnectionRelease，导致本次通话未接通。经查询，确认核心网侧主叫侧SBC概率性不转发被叫侧发送的183消息导致。解决措施核心网侧处理：MGCF做参数调整适配。效果比照MGCF做参数调整适配，未接通问题解决。案例合同关键页UE瞬间脱网案例分析问题描述某客户反响在使用4G通话后，会偶发瞬间脱网2秒左右，然后再正常驻留到4G网络。问题发生地点不固定，与地理位置无关。问题分析〔1〕排查无线侧参数通过核查3G、4G网络的无线侧3G/4G互操作参数、4G无线侧鉴权加密参数，未发现参数配置问题，并且也无影响业务的告警出现。〔2〕排查终端问题咨询客户得知，客户使用的根本是iphone6，在通话后会偶发性出现瞬间脱网2-3秒，然后正常驻留4G。在前期的终端摸底测试中，已经知道iphone6终端比一般终端信号灵敏度低5dB--10dB。因此，安排测试人员在客户投诉较多的区域周边片区，同时携带iphone6和Q801进行拉网测试和定点CQT测试。通过测试3G-4G重选、单发业务CSFB、并发业务CSFB等来模拟4G用户行为。协调3G侧后台人员同步对测试进行3G侧的IMSI和投诉用户的IMSI信令跟踪。通过大量的测试，成功地复现了偶发瞬间脱网问题。该问题偶发，和终端类型无任何关系。〔3〕分析信令前台信令分析〔路测信令〕从前台测试log可以看出，在信号较好，RSRP为-84dbm的情况下，仍然出现了脱网现象，从信令上可以看到TAU被拒、Attach被拒，原因是NetworkFailure，如以下图所示。后台信令分析〔基站侧信令〕通过信令分析可以发现问题出在用户从3G回LTE网络的时候TAU被拒、Attach被拒，导致UE瞬间脱网，被拒的原因是DNS解析失败〔如下面几个图所示〕，DNS解析失败说明DNS解析SGW有问题，需要DNS侧进一步配合排查。TAU失败：DNS解析失败：〔4〕核查DNS参数从3G侧给出DNS参数核查结果，可以看出DNS多配置了2个MME，如以下图所示。优化方案MME查询DNS按照UDP协议，最多不超过512字节，返回结果最多带4条记录，超过4条记录就会被丢弃。其中，返回结果所带的记录至少要包含一条SGW的解析，终端才能正常返回4G。当前在DNS的配置中配置了4个MME，这就存在一定概率返回的结果中所带4条记录都是MME，此时没有SGW解析，从而导致用户脱网。这就是用户小概率脱网的原因。咨询DNS侧，确认是由于MME组POOL时，在DNS侧配置了冗余数据导致概率性出现脱网。效果比照从配置来看：MME12的MMEC为8C，MME13的MMEC为8E。DNS多配置了8D和8F，如以下图所示。需要DNS删除8D和8F的配置即可解决。DNS侧修改参数后，安排测试人员现场4个多小时反复测试验证，未发现偶发脱网问题。询问之前发生问题区域的客户，反响未再发现脱网现象。案例合同关键页VOLTE参数设置导致eSRVCC无法切换现象描述测试人员在室内某处做eSRVCC测试项验证，主叫UE占用海勃湾酒厂办公楼-NLHF-2〔PCI=356、RSRP=-121.5dbm、SINR=-5.3〕，在15:07:30.569时间出现eSRVCC不切换，导致本次通话掉话。问题分析回放LOG发现，MO在PCI356电平在-105.25dBm，SINR3.9情况下发起VoLTE语音呼叫(即发送INVITE消息)，MT在PCI电平在-108.93dBm，SINR8.1情况下响应VoLTE语音呼叫((即发送INVITETrying消息)。从LOG分析发现主被叫呼叫信令流程正常，通话正常接通。此时MT向室内移动，在RSRP<-116dBm的情况时，MT开始持续上发B2事件。在屡次上发B2事件后，却未收到网络下发的切换命令，最终导致本次通话掉话。初步疑心VOLTE参数设置不合理，导致eSRVCC无法切换。问题定位1、由于本次通话满足eSRVCC门限却未发生切换，需要核查eSRVCC邻区LNADJG、LNHOG和LNREG，以及切换触发门限及判决门限等参数是否设置合理。经核查eSRVCC门限参数设置合理。2、从核心网的信令分析结果看，eSRVCCeMSC收到PS到CS切换请求后，通知目标MSC准备CS无线承载资源，然后发起SessionTransfer过程。然而此时无线再次发handovercancel导致流程失败，原因有可能是msc回响应超时。发起handovercancel原因值tS1relocprep-expiry〔9〕,tS1relocprep是eNB的定时器。从消息上看，这个定时器应该是1s。该参数应为3s。优化方案1、核查核查eSRVCC邻区LNADJG、LNHOG和LNREG，以及切换触发门限及判决门限等参数：4GA2测量事件〔触发异系统测量〕本系统判决门限〔含门限迟滞值〕-110dBm门限迟滞值hysteresis1dB触发时间timetotrigger320ms4GB2测量事件本系统判决门限〔含门限迟滞值〕-116dBm异系统判决门限〔含门限迟滞值〕-100dBm门限迟滞值hysteresis1dB触发时间timetotrigger320ms2、修改tS1relocprep定时器为3s。效果比照修改tS1relocprep定时器为3s后，该问题解决。在日常优化过程中，注意加大对全网VOLTE相关参数的核查力度，注意对新开站点的参数整体把控，后期优化过程中防止出现因参数设置不合理而导致eSRVCC切换失败而掉话。案例合同关键页Volte功能特性设置导致被叫未接通问题描述乌海二月份Volte摸底测试过程中，车辆沿新华南路由北向南行驶，被叫占用JYG01Orenminyinhang_1小区信号〔频点：38400；PCI：78〕，RSRP电平值为-86dBm左右，SINR值良好13dB；测试过程中被叫上发IMS_SIP_INVITE487，被叫终端触发TerminatingVolteAbnormal，出现未接通事件。被叫测试图例如下：问题分析基于被叫出现的未接通事件，被叫在09:36:58.050时刻触发IMS_SIP_INVITE183进程，随即在09:36:58.098收到网络侧的IMS_SIP_CANCAL消息，同时刻查看主叫信令，触发相应的流程一致，主被叫信令流程图如下：查看被叫IMS_SIP_CANCAL消息的具体原因如下：消息Content=Reason:SIP;cause=503;text="PT:ASR:INSUFFICIENT_BEARER_RESOURCES"；表示承载资源缺乏(503：SIP效劳器故障不能完成对正确消息的处理)，需要终止当前会话，随后被叫上发IMS_SIP_INVITE487(487：RequestTerminated，请求终止)；既然是“承载资源缺乏〞导致，那我们看看主被叫承载建立的情况；1〕主叫承载建立2〕被叫承载建立综合主被叫承载的建立可以看出，主叫已正常建立了SRB1+SRB2+2DRB(QCI=9;QCI=5)，但是建立第三个DRB〔QCI=1〕的时候出现异常；而被叫也是一样，被叫就有没建立DRB(QCI=1)的承载；由于Volte语音的接续过程必需要建立在承载之上，最终由于QCI=1的专用承载未成功建立，而导致出现“承载资源缺乏〞导致的IMS_SIP_INVITE487；呼叫流程终止；在测试过程中发现，在“JYG01Orenminyinhang〞附近出现较屡次的未接通、掉话等异常事件，出现屡次“RRCConnectionReestablishmentReject〞；最终锁定“JYG01Orenminyinhang〞站点存在问题，且疑心该站点VOLTE功能性参数设置有问题；确认站点无故障，小区状态正常；核查确认该站点及周边均无干扰；核查确认该站点邻区，发现该站点与周边存在邻区漏配现象；该站点在测试前期出现过站点故障，更换了基带单板，基站配置数据重做，才出现邻区漏配的现象；邻区添加后现场复测，仍然出现未接通现象；检查该基站的VOLTE功能性参数配置，发现该站点相关参数均为默认配置，且VOLTE的功能性开关未开启，如下：优化方案开启“JYG01Orenminyinhang〞站点VOIP特性设置，依据集团VOLTE参数进行调整；MO名称参数IDVoIP开关EutranVoipSupportSwitchROHC参数RohcSwitchHighestModeProfilesRLC/PDCP参数RlcPdcpParaGroupIdRlcModeDRX参数组DrxParaGroupIdEnterDrxSwitchLongDrxCycleOnDurationTimerDrxReTxTimerDrxInactivityTimereSRVCC参数HoModeSwitchAllInterRatHoCommGroupIdInterRatHoA2ThdRsrpInterRatHoA1A2HystInterRatHoA1A2TimeToTrigInterRatHoA1ThdRsrpInterRatHoGeranB1HystInterRatHoGeranB1TimeToTrigInterRatHoGeranB1Thd优化效果在完成“JYG01Orenminyinhang〞站点VOIP特性参数设置后，对“JYG01Orenminyinhang〞站点附近进行区域拉网测试，主被叫RB承载建立正常，均未出现未接通及掉话等异常事件；总体从前台测试，分析，定位，后台配合，逐步排查，最终确认问题根源；建议后续的工作流程，先总体后局部，保障现网所有站点的邻区的合理性、参数的一致性，防止问题的案例合同关键页智能网导致主叫未接通、被叫单通20S掉话问题问题描述测试车辆由东向西行驶，UE占用车辆检测站_2(PCI=273)小区，RSRP=71dB，SINR=23dB，无线环境良好，主叫UE在15：54：56.343出现未接通事件、被叫在2023-04-1915:55:21产生掉话。问题分析测试车辆在来远路西段由东向西行驶，占用车辆检测站_2小区，PCI=273，RSRP-74左右，SINR22，无线环境正常。主叫UE在第一次发送UPDATE请求后，被叫已有时回应UPDATEok消息，并且上发Ringing消息；但主叫并收收到Ringing消息，而是先后两次收到系统下发的UPDATE消息，导致未接通事件。被叫15:54:54.699振铃后，主叫未收到IMS_SIP_INVITE-Ringing消息，15:54:56.343核心网下发中断请求。20秒后，15:55:16.386被叫主动上发IMS_SIP_BYE-Request，被叫统计为掉话。炎强截图：由上图可以看出，SCPAS1返回给CSCF100trying后，CFCF01没有继续向SBC02下发100trying，而是直接丧失信令1分钟导致未接通事件。网络结构图：从网络结构看信令在IMS系统上传递后，还会经过业务平台传递，从而导致时延增加，信令丧失的概率变大。测试时延分析：测试日期呼叫建立时延(s)2023/2/222.142023/3/172.762023/3/192.732023/4/175.882023/4/197.432023/4/222.06从以往数次测试情况结果比照分析发现，测试呼叫建立时延从2月份的2.14s增加到4月份的7.43s，期间测试卡开启过智能网业务，然后跟踪主叫信令确定炎强平台存在智能网网元。4月22日更换未开启智能网业务测试卡后，时延从7.43s降低到2.79s，拉网测试也未出现此类主叫未接通，被叫单通20S后挂机现象。实施方案开启智能网业务会增加呼叫建立时延，且智能网网元容易导致信令丧失，易产生异常事件。现阶段建议关闭 。效果比照在关闭掉智能网之后，主叫未接通，被叫单通20S后挂机现象在拉网测试中没有复现，时延从7.43s降低到2.79s。案例合同关键页目标小区故障导致SRVCC切换失败问题描述SEQ平台上提取每天的切换失败次数，发现4月29号切换失败次数猛增，如下所示：对切换失败原因分析发现，原因值为Handover/Relocationcancelledbysourcesystem的切换失败次数明显增加，4月28号为23次，4月29号增加到247次，如下所示：从SEQ平台提取4月29号的详单，发现是Top用户1583395****和1383310****占用LTE小区〔政法学院3_1〕后做语音业务，切换到GSM小区SJGH0842政法学院3_0或SJGH0842政法学院3_1失败，累计失败214次，集中在13点到14点半之间。进一步分析发现，剔除29号切换失败后，多个LTE小区向同一GSM基站(政法学院3)发起切换，但全部失败，且持续较长时间，切换统计如下所示：日期LTE小区GSM小区切换请求次数切换失败次数4月21号-5月4号SJXIH1128政法学院新校区-HLHF_1SJGH0842政法学院3_136364月21号-5月4号SJXIH0533政法学院3-HLHF_1SJGH0842政法学院3_048484月21号-5月4号SJXIH0533政法学院3-HLHF_1SJGH0842政法学院3_19696Top小区地理位置：问题分析通过SEQ平台对切换Top小区分析发现，向GSM基站SJGH0842政法学院3切换的原因全部是Handover/RelocationFailurewithTargetsystem，如下所示：对其中一条切换失败信令分析如下：2023-05-0522:50:11.765，LTE终端发起HANDOVERREQUIRED请求，2023-05-0522:50:11.786MME向MSC发起SRVCCPSTOCSREQUEST，向GSM小区SJGH0842政法学院3_1发起切换。2023-05-0522:50:12.115MSC向MME发送SRVCCPSTOCSRESPONSE(Cause:73),提示GSM小区No

resources

available，导致切换失败：2023-05-0522:50:14.565LTE终端重新发起HANDOVERREQUIRED请求，GSM切换目标小区为SJDHM724政法新校区3_0，随后切换成功。对多条到GSM小区SJGH0842政法学院3_1的切换信令分析发现，全部提示Cause:73，GSM小区No

resources

available导致切换失败，紧接着切换到周边其他GSM小区且切换成功。问题共性明显，一般情况下ESRVCC切换失败原因为Cause:73的，大多由于2G邻区定义错误或2G无线原因造成，定位分析如下：第一步，核查LTE侧GSM小区定义信息，全部正确；第二步，核查GSM小区负荷情况，业务量低，无拥塞；第三步，核查GSM小区干扰情况，无干扰；第四步，核查GSM基站告警情况，无告警。第五步，核查GSM基站整体指标，发现3个小区接入异常，本系统切换正常，但话务量较低，统计4月24号到5月4号日均值，如下表所示：GSM小区名称日均呼叫占用请求日均呼叫占用成功日均TCH话务量日均无线切换失败次数SJGH0842_01115.519SJGH0842_11126.469SJGH0842_2668.667GSM基站有本系统切换，但接入存在问题，提交GSM侧安排人员现场测试，对问题进一步分析；同时提交核心网核查数据是否配置正确。影响范围：出现概率较大，影响用户感知优化方案由于GSM900基站SJGH0842政法学院3接入问题，ESRVCC无法切换成功，暂时删除到该基站的邻区关系，可以由同覆盖GSM1800频段基站SJDH0842政法学院3接续，等GSM基站处理好后再重新添加邻区关系优化效果通过邻区优化SRVCC切换失败事件大大减少。案例合同关键页二次注册IP端口号不一致导致注册失败问题描述在利用SEQ平台对现网用户的IMS注册成功率进行分析时，发现失败原因值为〞400BadRequest〞的占比较高为37.4%，严重影响整体的IMS注册成功率。用户无法成功注册IMS时将进行CSFB到GSM网络通话，无法使用VOLTE进行语音业务，影响用户感知问题分析通过SEQ平台的信令配合功能可直接定位到出现错误的失败信令，失败信令的详细解释为“Sip

key

parameter

invalid〞SIP关键参数无效；正常的IMS初始注册信令流程如下：1.UE在QCI5的默认承载上用于SIP信令向IMS发送注册请求；2.经过S-CSCF分配后注册请求送达S-CSCF；3.S-CSCF向HSS下载鉴权数据后给UE反回401消息，包含鉴权元素；4.UE重构注册消息，按照初始注册消息的路径发给IMS；5.经过S-CSCF查询、签约数据下载后，给UE反响200OK响应,表示初始注册成功；根据SIP协议规定，终端发初次注册请求后S-CSCF会返回401〔未授权〕响应要求终端进行认证，那么终端用户将发送第二个REGISTER请求，第二个请求包含相同的有关注册信息，并经过的路由与第一个REGISTER的路由完全相同。但是第二个REGISTER产生一个新的Cseq号码、branch参数以及一个新的From标签，并且该REGISTER请求会带入新的平安认证标签信息。比照异常用户第一次和第二次发送的REGISTER信令消息中的“Message

Header〞信息，发现前后callid一致，用户名一致，Cseq信息不一致。二次注册也同时产生了新的branch参数和新的Fromtag;但比照时还发现两条注册信息的头消息中的PORT-C、PORT-S、SPI-C、SPI-S端口配置信息不一致；二次注册的CALLID相同，但是IP端口号不一致，导致关键SIP信息错误IMS返回“400BadRequest〞注册失败；而比照正常的二次注册信令，相关端口信息是一致的详情如下：初步推断由于终端版本或芯片原因导致发送二次注册时端口号配置错误引发注册失败，出现该问题的终端类型99%为IOS终端，其他终端占比为1%。优化方案与终端场景沟通，升级版本优化效果终端升级后，指标ok。案例合同关键页VOLTE用户前转优化问题描述A打B，B转C，C转D，A与D接通。ABCD均为VOLTE号码，前转次数过多，排查后出现后续问题，导致未接通。测试号：问题分析A打B，B转C，C转D，A与D接通。消息中可以看到volte用户进行了二次前转，而集团标准要求前转一次，与集团标准不符。〔原因是VOLTE用户开户默认前转次数为5次〕实施方案ATSSGP侧执行如下脚本可将用户前转次数修改为1。USEME:NAME=对应ATS网元;优化效果采用以上处理方式解决将前转次数设置为1时，又出现如下问题：VOLTE用户在2/3G情况下，会出现与华为volte用户接续失败问题。案例合同关键页E-Nodeb参数设置错误导致接通时延较大问题描述湖南移动某地市在进行VOLTE例行测试过程中，测试设备虽注册在IMS网元上进行起呼，却进行CSFB呼叫，导致接通时延过长。问题分析经过分析定位，在轮滑广场进行定点CQT测试时发现该出无法进行volte正常通话，进行CSFB接通。Pioneer信令分析：14:31:53.418时，主叫测试终端占用YL0462_002_双双鸭轮滑广场-HLH_3进行上发INVITE消息，无线环境良好〔RSRP=-81.50，SINR=26.1〕，并于14:31:53.559收到网络侧回复INVITE100消息，此时信令消息正常，14:31:53.715时收到网络侧下发的异常信令INVITE503消息，内含“Content=Warning:39900000.00000.A.005.406.228.255.255.00045.00000002"MediaBearerLost"〞造成VOLTE起呼失败，进行CSFB业务测试；查看被叫信令流程，被叫于14:32:00.298收到网络侧下发的INVITE消息，并在同一时间上发INVITE100回复，但收到网络侧下发的CANCEL消息，查看信令内容依然是MediaBearerLost"；对主被叫终端建立承载信令进行细致分析查看，以主叫为例，在14:31:53.418时建立RRC连接，并进行SRB=1的信令承载，于14:31:53.481进行RRCConnectionReconfiguration，内含SRB=2的信令承载建立与3条DRB业务承载建立，根据现网Enodeb配置的eNodeB触发Polling的PDU数据量门限(字节)=“无限长“可以看出drb-Identity=2为QCI=5的承载，此时信令流程正常，但在主叫收到网络侧回复的INVITE100后并没有建立QCI=1的VOLTE专用语音业务承载，导致无法进行VOLTE业务，造成终端进行CSFB业务；SEQ信令跟踪分析：由于radioNetwork:not-supported-QCI-value(37)导致id-E-RABFailedToSetupListBearerSURes，以及Cause:Systemfailure(72)导致的CreateBearerResponse失败，造成VOLTE无法正常进行续儿进行CSFB。解决方案确认站点无故障，小区状态正常；检查业务无线环境，并进行干扰排查，周围无线环境良好，不存在外部干扰及内部干扰；检查状况及软件版本是否正确，测试终端功能正常，软件版本3.591403.1；经过核查，该问题站点于之前告警处理运维部门做过E-NODEB基站版本复原处理，导致局部功能开关处于关闭状态，经进一步核查发现VOIP能力开关为关闭状态，修改后复测正常，问题得以解决。优化效果文件名主叫起呼时间主叫结束时间呼叫类型代码呼叫类型呼叫结果振铃时长呼叫建立时长通话时长测试1_0419-143131126_UE12023年4月19日2023年4月19日2VoLTESuccess4.4639.343193.173测试1_0419-143131126_UE12023年4月19日2023年4月19日2VoLTESuccess14.40619.264204.322测试1_0419-143131126_UE12023年4月19日2023年4月19日2VoLTESuccess3.2928.08733.630文件名主叫起呼时间主叫结束时间呼叫类型代码呼叫类型呼叫结果振铃时长呼叫建立时长通话时长调整后_0421-150936582_UE12023年4月21日2023年4月21日2VoLTESuccess0.0002.16295.456调整后_0421-150936582_UE12023年4月21日2023年4月21日2VoLTESuccess0.0003.71195.672调整后_0421-150936582_UE12023年4月21日2023年4月21日2VoLTESuccess0.0003.70495.591案例合同关键页核心网入Pool导致切换成功率下降问题概述监控指标发现全网同频切换成功率从2月2号恶化严重，同频切换成功率从99.8%下降到99.0%左右。问题分析全网同频切换成功率恶化0.8%，分析切换失败原因：1、核查全网告警：发现全网无新增告警且基站运行状态正常，排除告警原因导致。2、核查参数配置：无线侧未进行参数修改，排查参数原因导致。3、是否存在重大操作：存在核心网入Pool操作，是否影响指标需进一步核查。3、是否存在TOP小区：存在TOP小区。分析TOP小区FH南岗隆马特-21指标如下：切换成功率在2月3日零时开始下降从一对一切换指标上可以看出FH南岗隆马特-21并非与所有小区切换都失败，失败原因为目标小区回复切换准备失败消息导致切换出准备失败。从切换失败的时间点可以初步判断问题发生在2月3日0点与入Pool时间点吻合。跟踪FH南岗隆马特X2和S1接口信令，X2接口信令失败原因为未知的MMECode按照流程X2切换失败后会进行S1切换，但是问题小区S1切换也失败，失败原因为ho-failure-in-target-EPC-eNB-or-target-system。比照问题小区X2切换成功与失败信令发现切换目标基站相同，但是有成功也有失败。成功时MMECode为192，失败时MMECode为196。问题小区S1配置S1接口标识S1接口CP承载号核心网的相对容量3173460-01-24320-194,460-01-24320-19540460-01-24320-192,460-01-24320-1935174460-01-24320-196,460-01-24320-1976175460-01-24320-198,460-01-24320-199切换目标小区S1配置S1接口标识S1接口CP承载号效劳核心网的全局唯一标识00460-01-24320-192,460-01-24320-193可以看出问题小区存在4条S1〔已经入Pool〕，切换目标小区1条S1〔未入Pool〕。由于源eNodeB是在pool内的，而目标eNodeB不在pool内，eNodeB所在MME认为切换是跨MME的，但是目标MME中有源eNodeB信息，认为是本MME内的切换，两个MME对切换的判断是不一致的，所以会切换失败。通过上述分析问题小区切换失败主要由于目标基站未入Pool导致。解决方案基站入pool调整。效果验证2月8日目标基站入Pool后切换指标恢复正常。1、对于入Pool的操作，建议同一个TAC统一操作，同一TAC不要分屡次否那么一定会造成切换失败2、由于两个TAC间是否有X2，已经组pool的TAC下的小区给未组pool的小区发送X2prepare的时候，会带上Pool内其他MME的MMECode，但是未组poolTAC下的小区并没有和这些MME相连，肯定会拒掉的，完全组pool后会正常。案例合同关键页超级小区切换入失败问题优化提升问题描述在2.2期工程设计批复的要求下需要对不符合设计批复的室分小区进行合并，在2023年10月份完成对工商学院、科技大学、博文职业技术学院、旅游学院共4所高校的超级小区合并工作，在超级小区合并后周边宏站对室分小区进行切换时出现大量的切换准备失败次数，由下表可知在10月份切换准备失败次数占切换失败总次数的20.34%，而宏站对高校室分问题占切换准备失败次数的43.39%，此问题对切换成功率指标造成了严重的影响。统计类型10月份指标明细切换失败次数5147657切换准备失败次数1046883室分站点切换准备失败次数454223切换准备失败问题占比20.34%室分站点问题占比43.39%问题分析无线环境测试卡伦工商学院西南1小区向工商学院5号公寓切换对的切换准备成功率仅20%左右，因此重点对工商学院内进行了相关测试。以下图为工商学院内各室分的分布情况：通过现场测试发现，该学校的宿舍楼覆盖场景较为特殊，宿舍楼道及宿舍外围墙体均为落地窗，导致室分信号外泄严重，各宿舍楼之间道路均由室分覆盖，宏站与室分邻区配置不全，导致校区内多处出现弱覆盖脱网现象，如以下图：通过对邻区关系的完善和对周边宏站的RF优化调整，该校园内覆盖问题得到明显改善，比照测试如以下图：无线环境优化前：无线环境优化后：在无线环境良好的情况下对吉林工商学院5号公寓周边进行现场测试，在测试过程中发现ENB已下发了A3事件的测量后UE不断在发送测量报告，如以下图：由于前台测试软件看不到到X2及S1口信令，因此需要与后台配合进行信令跟踪及分析。信令跟踪及分析对卡伦工商学院西南1小区进行切换对指标统计，发现此邻区关系仅在S1切换准备过程中失败，X2正常。S1切换整理流程如以下图所示：过程涉及源侧eNB、目标侧eNB及核心网。通过对源侧及目标侧小区同时进行信令跟踪，并对获取的信令进行分析。分析一段时间的信令，出现切换准备失败确实实仅在S1切换中。如以下图所示：UEGID=316的UE在进行切换时，当源侧小区289329_1在完成判决后向核心网发送了handoverrequired消息，但是却收到了handoverpreparationfailure消息。详细的信令解析如下：源小区289329_1在完成切换判决后，发送了handoverrequired，解析出的目标小区eNBID换算成十进制，确实为288417〔吉林工商学院5号公寓〕。至此证明此次切换源侧eNB的判决和动作均正常。但是接下来，源侧eNB却收到了来自核心网的handoverpreparationfailure消息，切换准备失败，原因值为“未知的目标小区〞如以下图红框所示。也就是说核心网认为目标小区是未知的，判断切换准备失败。首先疑心是否为目标小区的问题导致核心网作出此判断，因此查看工商学院5号公寓作为目标小区时收到其UEGID450对应的信令，可以发现只要工商学院5号公寓能收到核心网发来的handoverrequest消息，均做出了正确的判断并回复了handoverrequestacknowledge消息，可以证明只要目标小区能收到handoverrequest，就能完成正常的切换准备后的响应。如以下图所示：综上所述，通过对切换准备失败的信令进行分析，及对目标小区的比照核查情况，目前可以判断问题主要集中在核心网在收到handoverrequired后，会认为目标小区未知而直接发送handoverpreparationfailure。通过查看卡伦工商学院西南1小区的切换信令，可以看出对应的核心网为MME3，因此需要核心网的同事帮助确认为何eNODEB在发起handoverrequired后，MME03会认为目标小区未知而发送handoverpreparationfailure。实施方案核心网问题排查针对室分切换入准备失败问题与核心网同事进行沟通后，核心网侧提供了现网所有小区在MME中的链接状态，网优侧经过查询发现现网共14个小区在MME03中为未激活状态而在其他MME中为激活状态，所有的室分问题小区均在其中，就此情况再次与核心网进行沟通并得出以下结论：长春郊县核心网为爱立信设备，目前共有4个MME，所有MME与eNODEB之间链路是通过自学习功能建立起来的，核心网不会通过某种人为操作来删创链路，因此eNODEB与MME之间链路需要设备侧进行核查。ENODEBNameMM1状态MM2状态MM3状态MM4状态CCDH_邢家窝棚_ZLH_F21ACTIVEACTIVEUNACTIVEACTIVECCJT_工商一教4号3号公寓_ZLW_E24ACTIVEACTIVEUNACTIVEACTIVECCJT_工商1号2号5号公寓_ZLW_E24ACTIVEACTIVEUNACTIVEACTIVECCSY_长大旅游行政图书二至五宿_ZLW_E23ACTIVEACTIVEUNACTIVEACTIVECCSY_长大旅游一十十一公寓_ZLW_E23ACTIVEACTIVEUNACTIVEACTIVECCSY_科技大学实验实训楼_ZLW_E21ACTIVEACTIVEUNACTIVEACTIVECCSY_科技大学一至三教学楼_ZLW_E21ACTIVEACTIVEUNACTIVEACTIVECCSY_科技大学1至5公寓_ZLW_E21ACTIVEACTIVEUNACTIVEACTIVECCSY_科技大学6至10公寓_ZLW_E21ACTIVEACTIVEUNACTIVEACTIVECCSY_科技大学11至15公寓_ZLW_E21ACTIVEACTIVEUNACTIVEACTIVECCDH_岫岩窝堡_ZLH_31F4ACTIVEACTIVEUNACTIVEACTIVECCNA_华能电厂北_ZLH_22F6ACTIVEACTIVEUNACTIVEACTIVECCDH_刑家窝堡北_ZLH_V_22F1ACTIVEACTIVEUNACTIVEACTIVECCNA_农安拉拉_ZLH_22F6ACTIVEACTIVEUNACTIVEACTIVE统计以上站点10月份切换入准备失败数据可以看出此局部小区切换准备失败次数很高，且成功率很低小区名称[LTE]eNB间小区间异频切换入准备请求次数[LTE]系统内异频切换入准备成功次数[LTE]系统内异频切换入准备失败次数切换入准备成功率CCSY_科技大学实验楼_ZLW_E21_1152327993895293865.25%CCSY_7公寓_ZLW_E21_15273244963776985.27%CCSY_旅游学院奢岭校区二三公寓_ZLW_E23_15756949375819485.77%CCSY_科技大学2公寓_ZLW_E21_13051826472404686.74%CCSY_旅游学院奢岭校区图书馆_ZLW_E23_16472956869786087.86%CCSY_科技大学4公寓_ZLW_E21_12375120958279388.24%CCSY_科技大学3公寓_ZLW_E21_16285655750710688.69%CCSY_9公寓_ZLW_E21_16590958480742988.73%CCSY_科技大学6公寓_ZLW_E21_1100184890501113488.89%CCSY_旅游学院奢岭校区一公寓_ZLW_E23_15325547462579389.12%CCSY_旅游学院奢岭校区行政楼_ZLW_E23_13811340740489.40%CCSY_科技大学8公寓_ZLW_E21_11427541287371401790.18%CCSY_科技大学第三教学楼_ZLW_E21_18431176637767490.90%CCSY_科技大学1公寓_ZLW_E21_18025273385686791.44%CCSY_科技大学15公寓_ZLW_E21_12877926402237791.74%CCSY_旅游学院奢岭校区四五公寓_ZLW_E23_12618724039214891.80%CCSY_科技大学第一教学楼_ZLW_E21_1132621250975394.32%CCJT_工商学院4号公寓_ZLW_E24_12714122433470894.95%CCSY_科技大学13公寓_ZLW_E21_13318431570161495.14%CCSY_旅游学院奢岭校区十公寓_ZLW_E23_1146317139592672595.40%CCSY_旅游学院奢岭校区十一公寓_ZLW_E23_1204931195911902095.60%设备侧问题排查由上述分析可以看出室分站点与MME03之间状态为未激活状态，因此对吉林工商学院5号公寓在中兴OMC网管中S1及X2两条传输链路状态进行了查询：查询传输链路配置情况经过查询，室分站点工商学院5号公寓内共配有10条传输链路，其中前4条链路为S1链路，后6条为X2链路，如以下图：S1链路及X2链路状态查询经过查询发现，所有室分站点在S1AP模块内均未配置与MME03的链路，而是将MME03的链路配置到了X2AP模块中，导致了在MME03中问题小区为未激活状态。通过与工程侧核实，在9月份核心网进行了割接，由于所有的SCTP链路为网管系统自动生成，而当时网管数据中有局部站点由于网元断链等原因未能与MME状态进行同步导致了此问题。效果比照郊县核心网为爱立信设备，共4个MME组POOL，UE会随机在一个MME上进行业务，由于MME03与室分小区的链路未激活，导致UE在MME03上进行切换时会产生切换准备失败，而UE在其他三个MME上进行切换时不会产生切换准备失败的情况；通过设备侧核查，MME03与室分小区的链路未激活是由于核心网割接后，室分站点由于网元断链等原因未能与MME状态进行同步，导致网管系统错配了S1及X2的传输链路。各室分站点的传输链路手动进行重新配置后，室分切换入准备失败问题完全得到了解决。统计类型10月份指标明细12月份指标明细切换失败次数51476572606113切换准备失败次数104688350417切换准备失败问题占比20.34%1.93%案例合同关键页CSFB提升优化背景概述按照集团标准从3月28日开始对河北某市区进行测试，在