TD-LTE网络优化案例汇总

.32/33TD-LTE网络优化案例汇总项目名称文档编号版本号部门专业服务业务部作者版权所有大唐移动通信设备本资料及其包含的所有内容为大唐移动通信设备<大唐移动>所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权,任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容,违者将被依法追究责任。目录1.切换类问题21.1邻基站信息未配置成功21.2X2口不通导致的切换失败41.3硬件和传输故障61.4随机接入参数配置不当引起切换失败71.5重选优先级设置不一致导致异频无法切换111.6MME问题导致入POOL基站大量切换失败121.7开站数据模板不对引起切换失败171.8传输端口环回问题导致S1切换成功率低211.9府东街-3小区异常切换<A1/A2异频切换>242.接入类问题302.1MCC设置错误导致E-RAB建立成功率为0302.2核心网问题导致REAB建立失败312.3LTE多模终端自由选择网络不能接入LTE网络问题分析342.4默认网关配置错误372.5核心网算法问题392.6信令面流程正常业务面无法上网案例422.7三星NOTE23信号标识不显示问题分析案例433.速率类问题483.1下行子帧调度不满导致平均下载速率低问题分析483.2传输受限引起的速率问题513.3CFI相关设置影响LTE拉网速率分析524.CSFB类问题594.1UE未收到Release消息重选到TDS594.2网络侧不下发Release消息614.3MME配置TA与LA映射错误导致开机联合注册失败634.4并发业务导致CSFB失败64切换类问题1.1邻基站信息未配置成功问题描述：测试发现NBHS维科上院FHTL-1PCI=487与NBHS青林湾西FHTL-0PCI=438之间切换失败。从前台测试LOG可以看出,18:10:8.533占用NBHS维科上院FHTL-1PCI=487上报MR,目标小区NBHS青林湾西FHTL-0PCI=438,没有响应,18:10:50.42秒后上报第2个MR。两个小区的位置图层：问题分析：ATP抓包反馈情况：第一个MR没有反馈：第二个MR,启动切换,但是切换准备失败,反馈传输资源不足造成,最后还是完成切换,前台测试切换至NBHS锦江年华FHTL-2PCI=320非NBHS青林湾西FHTL-0PCI=438。查看导出的邻区关系列表,NBHS维科上院FHTL-1PCI=487与NBHS青林湾西FHTL-0PCI=438两个小区之间存在邻区关系,但是查看配置文件,发现青林湾西邻基站中未配置维科上院的邻基站信息〔200914与200894。解决措施：添加青林湾西邻基站中未配置维科上院的邻基站信息。处理效果添加两个基站之间的邻基站信息后,小区间切换支持。附件或日志：1.2X2口不通导致的切换失败问题描述：测试车辆由南向北行驶至前XX路路段,UE占用NBYZ四季瑞丽1小区PCI483的信号,在该路段接收到主服小区的RSRP-106dBm,无线信号在该路段覆盖较差。通过UE上报的测量报告发现,UE有上报切换目标为NBYZ现代轿车城3小区PCI473,该小区的RSRP-88dBm,信号良好；但未发生切换。无线覆盖示意图测量报告示意图邻区关系示意图问题分析：测试车辆由南向北行驶至前XX路路段,UE占用NBYZ四季瑞丽1小区PCI483的信号,在该路段接收到主服小区的RSRP-106dBm,无线信号在该路段覆盖较差。通过UE上报的测量报告发现,UE有上报切换目标为NBYZ现代轿车城3小区PCI473,该小区的RSRP-88dBm,信号良好；但未发生切换,经核查邻区发现NBYZ四季瑞丽1小区与NBYZ现代轿车城3小区之间未添加邻区关系。解决措施：添加这两个小区邻区关系之后仍不切换,检查小区状态,状态运行正常,无故障。随后检查这两个小区的X2接口连接指示发现,配置状态为"不存在",修改为"存在"后,切换正常。处理效果把X2接口连接指示配置状态修改为"存在后"切换正常。1.3硬件和传输故障问题描述:5月27日,蒋王庙试扩L329138,00蒋王庙试扩L-2_2站内切换指标如下：服务小区名称服务小区IDeNodeB内切换出成功次数eNodeB内切换出尝试次数eNodeB内切换出失败次数ENODE内切换成功率蒋王庙试扩L329138,00蒋王庙试扩L-2_2329138911281.82%32913856183.33%32913856183.33%32913846266.67%从KPI的统计表中可以看出,基站内切换成功率在一段集中的时间内较差,而之前的时间段ENB内切换成功率均为100%。问题分析：根据下图上午MR计算出目标小区的RSRP为-90dBm,覆盖良好。1.4随机接入参数配置不当引起切换失败问题描述：使用L1*Outum8.0进行测试时候发现XXXXLTE网络新入网很多基站在无线环境很好〔RSRP-80dbm左右&SINR20左右的情况下基站内小区间切换均失败,在测试中时出现以下情况,UE在正常接入小区后,UE上发测量报告,然后基站下发重配置消息,UE上传重配置完成消息,从无线口信令消息看切换已经完成。但是从测试过程中发现并没有切换成功,而是经过2秒后基站下发MIB消息、系统消息,然后UE上传连接重建消息,接着基站下发连接重建命令,UE上传连接重建完成,到此UE应该是重新接入小区,并不是切换。具体个例如下：同时在基站侧用ATP进行跟踪时,出现如下图情况：UE上传测量报告,基站下发连接重配置消息,但UE在2秒内无回应或者基站在这2秒内没收到重配置完成消息,于是2秒之后UE上传系统消息1,而基站则下发系统消息2,然后就是上传连接重建请求消息,基站下发连接重建命令,接着UE上传连接重建完成,到此UE重新接入小区问题处理流程：1、首先针对小区内邻区进行检查,邻区配置正确；2、由于是双模站点,所以提取同样为双模站点的XX参数进行对比,发现关于切换的参数均配置正确；3、通过以上分析发现发生切换时候手机能上报重配置完成消息,但是基站侧没有收到这条消息,说明有可能是接入参数有异常。4、研发支持：通过收取CDL/ATP/基站公共日志进行分析以后研发怀疑是随机参数设置不当造成的,随机接入参数零相关配置参数现场设置为11比较大,建议调整为默认的设置3以后进行试验。问题解决效果：将零相关配置从11调整为3以后从下图可以看出调整前测试还是出现切换失败,但是调整以后基站内小区间切换成功,对基站间相邻小区的切换也成功,说明该问题已经解决。总结：根序列索引规划建议现网中宏站Preamble格式通常选择格式0,室分为格式4；宏站PRACH配置索引设置为3,室分为51；室外推荐的零相关配置为3,对应低速非受限取值为18；室内站点零相关配置为3；对应的Ncs值为8；根序列索引的配置和PCI相关：若室外宏站的零相关配置采用3,对应的Ncs值为18,这样每个根序列能产生838/18=46个preamble码,每个小区需要产生64个preamble码,故需要64/46=2个根序列产生一个小区所需的premble码,故838个索引能产生838/2=419个小区所需的preamble码,所有小区重复利用这419个,为了避免相邻小区的根序列索引冲突,故根序列索引值和PCI关联,即根序列索引=〔PCImod419*2；室分站点零相关配置采用3,对应的Ncs值等于8,这样每个根序列能产生138/8=17个preamble码,每个小区需要产生64个preamble码,故需要64/17=4个根序列产生一个区所需的premble码,故138个索引能产生138/4=34个小区所需的preamble码,所有小区重复利用这34个,为了避免相邻小区的根序列索引冲突,故根序列索引值和PCI关联,故根序列索引=〔PCImod34*4。排查基站告警,在查询基站告警日志发现在该时间段存在小区退服,传输故障,X2链路故障的告警。如果由于小区重复退服,可能导致站内切换成功率下降。告警名称告警级别告警源网元类型产生时间小区退服,传输故障主要蒋王庙试扩L329138,小区2ENB2013-05-2720:38:16X2链路故障次要蒋王庙试扩L329138,SCTP链路2ENB2013-05-2720:02:05小区退服,传输故障主要蒋王庙试扩L329138,小区2ENB2013-05-2719:28:36问题解决：安排基站人员上站排查,重现建立X2链路后告警消除。解决效果：28日现场排除告警后提取当日指标进行验证。下表为蒋王庙28日全天级指标,已有明显提升。服务小区名称服务小区IDeNodeB内切换出成功次数eNodeB内切换出尝试次数eNodeB内切换出失败次数ENODE内切换成功率蒋王庙试扩L329138329138261264398.86%1.5重选优先级设置不一致导致异频无法切换问题描述：XXXXLTE实验网新开局对室内和宏站之间异频切换进行验证。使用L1*Outum8.0/华为MIFI*Outum8.0进行异频切换验证；验证参数配置：1、X2链路、邻区关系与小区异载波信息配置完成；2、A1A2算法均开启测量；3、GAP测量打开；从验证结果发现室分可以切换到宏站,而从宏站无法切换到室分；问题分析：在进行切换验证测试时发现当师大商学院〔宏站的RSRP值达到-112dbm且嵩明XX师范大学商学院动感厅〔室分的RSRP达到-69dbm时,已经达到切换门限,但是UE仍驻留在师大商学院2小区中不发生切换,最终由于信号过低终端进行重建而驻留到室分基站,切换失败,查看信令消息时,此时UE已经上传测量报告,而且也有重配置消息下发但是终端并没有发生切换,对重配置消息进行解析发现该重配置消息并不是用于切换的重配置消息。如下图所示问题处理流程：1、对两个基站的X2链路及邻区关系进行删除再重新创建,并且重新配置异频载波信息,切换问题未解决；2、由于室外宏基站是双模站而室分是单模站,因此对单模站点的"单模RRU帧头偏移置"进行设置,由无偏移设置为700us,参数修改以后进行验证,切换问题未解决；3、经研发老师指导发现师大商学院基站的小区重选公共参数中的"小区重选优先级"设置为3,而EUTRAN异频载波信息中的"小区重选频点优先级"设置为1。将小区重选公共参数中的"小区重选优先级"设置为1,与EUTRAN异频载波信息中的"小区重选频点优先级"设置保持一致,切换问题解决；问题解决效果将师大商学院基站的小区重选公共参数中的"小区重选优先级"设置为1,与EUTRAN异频载波信息中的"小区重选频点优先级"设置为1保持一致,通过验证发现问题已经彻底解决。总结：目前我司设备的异频切换算法,采用A1/A2/A3/A4/A5算法,A1用于异频关闭,其中A2用于开启异频测量,A3用于启动切换请求〔当A3用于异频时必需保证源小区和目标小区的小区重选优先级一致,A4用于异频高优先级切换,A5用于异频低优先级切换；在异频切换时,若仅开启A2、A3测量开关,小区重选公共参数中的"小区重选优先级"与EUTRAN异频载波信息中的"小区重选频点优先级"设置必须一致。出于某种目的,"小区重选优先级"必须设置成不一致时,需要开启A4或者A5测量开关用于异频测量。1.6MME问题导致入POOL基站大量切换失败问题描述：XXKPI组发现3月8日后全网的切换成功率一直在恶化,提取切换失败TOP小区分析CDL发现,切换失败大部分为目标小区回复切换准备失败携带原因为transport-resource-unavailable。问题分析：在基站版本45.16版本升级后,XX全网也出现了大量的切换失败,失败原因为transport-resource-unavailable,排查定位过程发现是基站的邻基站中SCTP链路索引对应错误导致,基站升级后解决。而近期又出现了相同原因的切换失败,所以第一时间核查了全网的X2链路、邻基站,但是发现并没有异常,于是基本排除是X2链路、邻基站的原因导致目标小区切换准备失败。于是,分析TOP小区,以上渡派出所-DLH〔ENBID:418705为例,提取该站CDL日志分析。切换统计显示站内切换和S1切换都正常,X2切换成功率只有10.79%,而且切换出失败中99.91%是"切换目标侧准备失败",通过切换分析可以看出,1082次切换失败,全部是往ENBID:418644切换,而且释放原因全部为transport-resource-unavailable。现场已知该原因释放的问题主要是X2资源导致的,而已经核查过全网X2配置,且确认418705和418644之间完全正常。 在X2切换成功的详表中发现目标基站ID为418644的切换有成功的,于是对比时间相近的切换失败和切换成功。通过对比x2HandoverRequest的IE值,发现切换成功时该消息拾的GUMMEI中MME-CODE为'D0H〔208对应XXMME,而切换失败时的MME-CODE都为'10H<16>对应XXMME。在OMC上查看418705的S1链路状态,发现到XXMME的S1链路状态为"与对端连接成功"〔正常,而与XXMME的S1链路状态为"驱动建立成功"〔故障。 再分析目标基站418644的CDL日志,发现该站有大量的S1建立失败信令,检查S1SetupRequest的各IE值都正常,S1SetupFailure携带原因为message-not-compatible-with-receiver-state。为区分是基站问题还是MME问题,分别删除再添加该站到XX和XX的MME,到XXMME的S1链路马上建立成功,到XXMME的S1链路仍然故障。对比基站给两个MME发送的S1SetupRequest的IE值完全一致,说明基站的S1SetupRequest消息并没有问题,问题出在XXMME上。 分析剩余的TOP小区,发现都存在与418705一致的现象,即目标小区到XXMME的S1链路故障。 目前XX全网基站已开启S1-FLEX算法,全部入MMEPOOL<XX、XX两台MME>,且两台MME的能力都配置为50,为负荷分担方式组网,所以正常入POOL的基站下接入,UE有50%的概率接入到两台MME上。 通过信令和TS36.413我们可以知道,ENB发起S1SetupRequest,MME回复S1SetupResponse会携带MME的相关信息〔PLMN,MME组号,MME编号,MME能力等。,而S1链路建立失败时ENB获取不到相应的MME的信息的。 假设ENB1正常入POOL〔两条S1〔S1a,S1b正常,ENB2〔其中1条S1故障〔S1a正常,S1b故障,当UE在ENB1下从S1a接入,往ENB2切换,由于ENB2的S1a是正常的,ENB2上有S1a对应MME的信息,切换可以正常进行。而当UE在ENB1下从S1b接入,往ENB2切换,由于ENB2的S1b故障,ENB2上并没有S1b对应的MME信息,所以切换需要的S1资源无法成功准备,所以会给ENB1回复HandoverPreparationFailure,导致切换失败。解决措施： 在分析出是XXMME问题导致全网切换失败后,联系XXMME人员,提供S1建立失败的基站信息,MME侧抓包、提取MME日志确认是MME的问题。只要MME处理完后基站S1正常建立,切换成功率即可恢复。 虽然切换成功率恶化的原因已查明为MME故障,但是在定位过程中基站给出的切换准备失败的Cause值误导了现场的问题定位。 对于目标S1链路故障导致切换准备失败的现象,在和NSN,ZTE跨厂家切换的时候已经分析过,但是对于这类问题,其他厂家一般在HandoverPreparationfailure中携带的原因为"UnknownMMECode",而我们基站是回复"transport-resource-unavailable",影响了问题的定位效率,而TS36.423中对这类原因有注释,其他厂家此类问题的原因归类为"UnknownMMECode"更能有效指导问题定位。 与研发确认,目前基站版本eNB只是发现用户所在的Gummei与自己连接的MME不一致,直接判断失败。并没有进一步判断是GroudID不正确,Plmn不正确,还是MmeCode不正确。为便于容易指导现场定位,后续基站版本会加入相应判断,优化Cause值。处理效果： 3月15日凌晨,XXMME人员针对S1无法建立的问题现场处理后,原因到XXMME的S1链路故障的全部恢复正常,当天全网的切换成功率就回升到95%。1.7开站数据模板不对引起切换失败问题描述：近日新开LTE室VIP站点泗阳移动公司新大楼,添加完邻区后状态正常,现场发现无法切换到室外宏站,但是室外宏站可以切换到室内,随后对该问题进行分析定位。问题分析：无线环境分析CellNameECITACBandWidthFrequency_DLPCI宿迁泗阳移动新大楼LEW-1020559202360500宿迁泗阳新世界LF-102055920189084根据现场测试,宿迁泗阳移动新大楼室外最强宏站为泗阳新世界LF-1,RSRP电平在-90~-100之间,相对较弱,但根据小区算法-切换算法-邻小区RSRP门限为20〔-120dbm,室外电平满足切换入的要求。信令分析1、通过前台新令分析,在由室内到室外过程中,UE发送MR后收到RRC释放请求,并没有进入RRC重配过程,如下图：从后台上看为收到测量报告后,eNB向EPC侧发送UEContextReleaseRequest释放上下文,同时向UE发送RRC释放,最终无法完成切换。分析eNB释放上下文携带的原因为ue-not-aivilble-for-ps-service,该原因与CSFB重定向到2G的原因一致,对RRCConnectionRelease进行分析,发现携带GERAN频点信息,初步判断为进入了盲重向过程,而没有进行异频信息测量。2、现场随后进行参修改,关闭小区-小区测量-A3事件配置1.1-测量相关算法中的小区间干扰协调算法,同时将A1和A2RSRQ门限值都修改为-50,现场测试发现UE一直上发测量报告,但无法收到携带异频〔38350的RRC重配置消息,导致终端一直无法进行异频测量,该问题为现场将A1/A2设置一致导致异频测量无法启动。3、现场将GERAN异载波信息、GERAN邻小区关系删除,同时将A2RSRP门限值修改为-90,同时关闭A1事件配置〔关闭A1事件配置为更换定位问题,终端始终开启异频测量,测试发现能够正常进行切换。4、后台重新将GERAN异载波信息、GERAN邻小区关系添加后测试,又再现RRC释放,现象和之前一样,判断为添加GERAN异载波信息后上报本小区电平测量达到一定的门限,触发了盲重定向过程,而该过程门限高于异频切换门限,导致在室内到室外移动过程中,室内信号渐弱,在室外电平未满足切换之前发生了盲重定向,释放RRC,其中A2RSRP门限、系统间测量门限、和盲重定向门限设置如下当时无线环境RSRP电平在-90~-100之间,有可能启动系统间测量,但是若盲重定向门限为-118dbm,则不满足盲重定向门限。5、重新核查盲重定向门限,发现该站点小区-小区算法-异系统互操作中无重定向门限,如下：而正常的站点含有盲重定向门限,如下：问题定位：经过上述分析,将问题定位为RRC释放的原因为发送了盲重定向,而该站点模板或版本存在问题,无盲重定向门限设置导致。盲重定向门限为TD-LTE_V3.20.03版本后添加的,该站点开通时项目已统一使用45.17.03的开站模板,进一步核查,发现该站点运行基站软件包版本为TD-LTE_V3.20.00.45.17而使用45.17.03模板进行开通导致,随后对该站点软件版本升级到TD-LTE_V3.20.03后测试正常。未出现盲重定向问题。后续建议：该问题最终定位为站点开通模板和站点运行的软件包版本不一致导致,由于版本升级前后的变更可能导致个别新增的参数和功能在老版本的站点中出现问题,最终导致异常事件发生,建议在后续站点开通过程规范版本和模板,开站数据模板注明对应的版本信息,保证督导使用现网最新统一的版本和基站数据进行站点开通。1.8传输端口环回问题导致S1切换成功率低问题描述：XX两站之间S1切换失败次数较多,影响全网KPI指标。查看SCTP链路故障,显示驱动配置成功。问题分析：查看CDL：UE上发MR之后,由于X2链路故障基站判决走S1切换。在经过200个半帧后迟迟未收到核心网的回应,导致S1切换定时器超时后向EPC发起切换取消的命令。这里有两种可能,一种是基站侧消息发出去了核心网没有收到。一种是核心网下发了回应消息而基站侧没有收到。定位过程：出现这种情况受限切换走S1就不正常,需要先排查X2链路故障的原因。通过查看核查邻区关系,路由配置以及传输参数没有发现问题。用LMT登录基站在诊断测试里互相ping对端基站的业务IP都不通,在A站Ping自己的网关发现存在丢包现象。查看SCTP链路显示驱动配置成功,A站为服务器,B站为客户端。删除A站的服务器后A站又自动建立。然后同时删除两端的SCTP链路,在A站建立客户端,然而B站却无法自动建立服务器。说明B站收不到A站的发包,而A站却可以收到B站的发包。因此怀疑传输侧存在问题,导致X2链路不通。基站的网关跟基站间就相当于区域网内直连,如果这样ping通的情况都会有丢包,说明基站跟网关的物理链路很不好,即基站消息发送的第一结点都不能保证传输质量。而传输质量不好必然会影响切换的成功率。为进一步定位是否是传输问题影响的切换,进行以下操作：打开电脑的cmd命令窗口,telnet登陆基站,使用OM管理IP,例如：telnet,用户名和密码都是root然后直接敲命令ping对端基站,ping时候使用X2对端业务IP,例如ping9-s200-c10[-s<SIZE>表示ping包大小,-c<CNT>表示ping次数]之后会在cmd命令窗口,看到如下示例,如果PTN端口有问题,会看到好多回复报文,TTL从64减到1才会停止。如果两个站ping不通,可以选另外一个可以ping通的X2对端基站,以便发现PTN内部环回问题。传输端口环回：传输正常：定位结果：现场将此问题现场呈现给传输侧,传输重新把该站的传输数据做了一下之后SCTP链路全部恢复正常,提取KPI指标,没有再出现S1切换,且X2切换成功率明显上升。1.9府东街-3小区异常切换<A1/A2异频切换>问题描述：府东街基站天线可视20米距离不能切换到该基战,始终占用临近乡政府基站信号问题分析：8月8日路测人员反映在府东街基站附近面对天线可是条件20米距离只能接收到乡政府基站两个扇区的信号,收不到府东街的信号。测试工程师打至后台,确认基站状态正常,功率参数正常。使用CDS设备到现场测试发现：图中红色圆圈位置距离乡政府基站560m,距离府东街距离280米,在已经越过府东街280的情况下,而且乡政府1小区RSRP已经达到-99dBm的情况下没有切换到府东街基站。核查基站状态、功率参数,都在正常范围内。为了确认是否为基站问题,做了反向测试,发现从府东街到乡政府方向能正常占用府东街信号。下图是反向测试截图,表明终端可正常占用府东街信号：反向测试结果表明,问题不在基站侧。反复测试时发现,从乡镇局到府东街方向,终端在占用乡镇局信号时不上报A2消息,而且乡镇局的信号已经到了-99dBm时都没有下发邻区列表,初步分析问题出在乡镇局,不是乡镇局到府东街不能切换,应该是乡镇局参数配置有误。核查后台参数后发现乡镇局为F频段基站〔38350,府东街为D频段基站〔37900,乡镇局基站A1配置为-98dBm,A2配置为-100dBm,府东街基站A1配置为-88dBm,A2配置为-90dBm,两个基站的事件迟滞参数配置都为2。在LTE系统切换分为三个步骤：在切换过程中的异频异系统测量主要由A1、A2事件控制,A1事件表示服务小区质量高于一定门限,当满足事件触发条件时,UE便上报测量报告,eNode停止异频异系统测量；A2事件表示服务小区质量低于一定门限,当满足事件触发条件时,UE便上报测量报告,eNode启动异频异系统测量。A1事件的触发条件：Ms–Hys>ThreshA2事件的触发条件：Ms+Hys<Thresh按照A1、A2的触发条件,我们可以计算出从乡政府到府东街方向测量控制行为的伐值A1:MS-2>-98MS>-96dBm时停止异频异系统测量A2:MS+2<-100MS<-102dBm时启动异频异系统测量这就解释了为什么从乡政府到府东街方向异常切换的原因是A1、A2参数设置不合理导致。网络优化本身就是个性化和精细化的工作,A1、A2参数的设置并没有死板的规定,在很多特殊或者精细化场景A1=--98,A2=-100并没有什么错误,但对于乡政府--府东街这个方向这样的参数设置显然是不合理的,显然当时配置参数的工程师仅仅从一个方面考虑问题,没有全面考虑参数配置对网络的影响。对该问题的分析讨论不仅仅是为了解决一个简单的异常切换问题,重点是讨论分析不同场景的切换策略。我们可以通过分析乡政府周边站点的情况来看当时配置A1、A2参数的原因：专题地图中基站中心不同颜色的圆点代表的频率信息,扇区颜色代表模三信息。红色为D频段37900,绿色代表F频段38350,从专题地图中可以明显看出F频段的乡镇局周边被D频段的站点所包夹。如果按照正常场景或者正常优化思路,这种场景为了规避数量较多的D频段基站的模三干扰A1=-98dBm,A2=-100dBm的参数配置可以使终端在业务态时尽量占用无线环境较为纯净的F频段的信号。但是这样的参数设置没有考虑到乡政府-府东街一线由于特殊的无线环境,这两个基站1扇区的信号都被限制在基站所在的道路上,那同时外边的信号也基本不能覆盖到该区域,我们可以通过这条道路的SINR值来印证。参数修改前乡镇局1小区与府东街1小区的切换点参数修改前乡镇局1小区与府东街1小区的切换点从SINR图示我们可以看到在这条无线环境相对比较封闭的道路上无论占用F频段的乡政府-1小区还是D频段的府东街-1小区,SINR都非常好,绝大多数采样点SINR值都在15-40范围内,即便是少数几个不好的采样点SINR值也在9-15之间,这已经是很好的无线环境,在这种无线环境中让终端占用F频段的基站并没有明显的益处,反而会拉低这个小范围的下载速率,导致基站利用率降低。由于TD-LTE和TD-SCDMA都是时分双工系统,为了最大限度的降低两个系统的上行干扰必须拉起这两个系统的特殊时隙,也就是要保证TD-SCDMA和TD-LTE在特殊时隙上同发同收,否则会因杂散或者互调问题导致下行强干扰信号影响上行。基于以上原因F频段基站的特殊子帧的配比必须是3：9：2,按照LTE协议规定,当DwPTS符号配比>=9时,才允许传送业务数据,F频段的基站DwPTS配比为3的时候不符合可以传送业务数据的条件,因此在F频段的基站特殊子帧不能传送业务数据。D频段站点因为不涉及与其他网络的杂散或者互调干扰问题,特殊子帧的符号配比可以在协议规定范围灵活选择,当前网络D频段的特殊子帧的符号配比为10：2：2,按照这种符号配比,D频段基站的特殊子帧的下行导频时隙可以传送业务数据。根据以上分析我们可以得出结论,在SINR值相当的情况下D频段基站的下载速率大于F频段的基站。我们可以通过A1、A2参数修改前后的路测结果验证以上结论。参数修改前的下载速率渲染图参数修改后的下载速率渲染图从下载速率我们可以看到,修改参数后在乡政府到府东街路段下载速率得到明显改善。解决措施： 修改乡政府1小区A1事件参数,原参数设置A1=-98的Bm,修改为-86dBm修改乡政府1小区A2事件参数,原参数设置A2=-100的Bm,修改为-88dBm修改乡政府1小区A3事件参数,对于乡政府-1的邻区府东街-1,小区个性偏移原值为0,修改后的值为5。修改的目的：让终端更快的切到下载速率更好的D频段。接入类问题2.1MCC设置错误导致E-RAB建立成功率为0问题描述：在分析TOP小区时,发现HD堤村1小区无线接通率为0,其中RRC连接成功率为100%,E-RAB建立次数及成功率均为0,与前面RRC连接次数极不对称,统计指标如下图所示：问题分析：首先通过CDL对本基站1小区的E-RAB建立进行分析,从信令流程上具体定位问题发现在哪个环节；根据CDL信令流程或提示再核查基站的告警状态、是否故障或者开站数据是否有误〔如SCTP链路、VLAN、路由、基站ID、MCC、MNC、TAC等；问题排查：分析基站CDL日志方法步骤：通过分析本基站1小区的CDL日志,发现在本小区下,有终端一直进行RRC连接,但连接完成后直接释放,即不进行E-RAB建立,信令流程图如下：核查基站的开站基础数据方法步骤：通过信令得知UE不进行E-RAB建立,首先需要核查本小区是否存在故障或者告警,通过核查后无这方面的因素；同时分析所得因为UE不进行E-RAB建立,应该把参数核查重点放在跟核心网有关的参数上面,因此通过检查基站的参数发现本基站1小区的MCC设置为640,如下图所示：正确设置应该为MCC为460。处理过程：将本基站1小区的MCC由640更改为460。处理效果将MCC更改正确后的本小区指标正常,如下图：延伸1、当一个小区RRC连接成功率很高,但E-RAB建立成功比较低,一般可确认空口不存在问题,此时一般可以从开站数据核查开始,即主要涉及UE接入核心的参数进行核查,诸如MCC、MNC、TAC等；2、在督导开站过程中一定要注意基站基础数据的配置是否正确,否则一个小小的失误将会造成基本的指标直线下降。2.2核心网问题导致REAB建立失败问题描述：XX在海峡会展保障期间出现大量ERAB建立失败,18:00~19:00,E-RAB失败2100次,严重影响全网指标,造成用户感知较差。问题分析：查看CDL：核心网在发起S1InitialContextSetupRequest,之后AP侧上报两次AP_PER_ERROR,基站直接回复S1InitialContextSetupFailure,失败原因为semantic-error定位过程：经过查看核心网发出的上下文建立请求消息中,发现AMBR携带的值为0,根据协议,eNB判断此消息非法,会导致上下文建立失败,影响上下文建立和承载建立的KPI。现场和诺西的核心网厂家确认,此问题为诺西EPC的已知BUG。具体协议如下：0UEAggregateMaximumBitRateTheUEAggregateMaximumBitrateisapplicableforallNon-GBRbearersperUEwhichisdefinedfortheDownlinkandtheUplinkdirectionandprovidedbytheMMEtotheeNB.IE/GroupNamePresenceRangeIEtypeandreferenceSemanticsdescriptionUEAggregateMaximumBitRateApplicablefornon-GBRE-RABs.>UEAggregateMaximumBitRateDownlinkMThisIEindicatestheUEAggregateMaximumBitRateasspecifiedinTS23.401[11]inthedownlinkdirection.>UEAggregateMaximumBitRateUplinkMThisIEindicatestheUEAggregateMaximumBitRateasspecifiedinTS23.401[11]intheuplinkdirection.ReceivingboththeUEAggregateMaximumBitRateDownlinkIEandtheUEAggregateMaximumBitRateUplinkIEequaltovaluezeroshallbeconsideredasalogicalerrorbytheeNB.定位结果：现场将此问题呈现给诺西厂家,希望能尽早解决此BUG。KPI指标目标目前已恢复正常。2.3LTE多模终端自由选择网络不能接入LTE网络问题分析问题描述：IPHONE5S和L1终端在自由选择网络模式下,无法驻留在任何网络。在手机上看,是手机显示LTE网络,或者2G/3G网络,但是不能进行任何业务,打和上网。而且信号格显示是空的,即没有信号。而IPHONE5S和L1终端终端在华为的站点下,是可以正常驻留并进行CSFB业务的。L1终端选择仅LTE模式下,可以正常接入LTE网络,并且进行数据业务。使用HISIE5776测试此站点,无任何功能性问题,可以接入,业务正常。将IPHONE5S在问题站点下重新开关机,提取基站CDL日志,从CDL日志的信令流程来看,信令走到了SecurityModeCommand就释放了,见下图：图1-1IPHONE5S开机CDL信令流程点开SecurityModeCommand,里面的详细内容见下图：图1-2SecurityModeCommand消息内容问题分析：1、一般接入问题需要检查站点配置文件中的接入参数、TAC、IP地址和路由关系等参数设置。本案例中,使用L1和E5776可以正常接入网络并且进行数据业务,说明基站侧接入参数、TAC、IP地址和路由关系都没有问题。2、商用终端的完整性保护算法不能为空算法,这在早期的网络优化过程中也遇到一些商用终端不能接入LTE网络的问题,后来都是通过修改完整性保护算法优先级来解决。3、对于有CSFB功能的LTE终端来说,联合附着不成功,会导致终端不能驻留在LTE网络。典型的CSFB业务流程主要包括联合附着、位置更新、主叫<MO>CSFB流程、被叫<MT>CSFB流程以及去附着等。启用CSFB功能的用户的附着流程是基于联合GPRS/IMSI附着流程来实现的。问题处理流程：由于CDL日志里面,完整性保护算法为eia0,即为空算法,导致终端不能接入。因此需要检查基站侧的完整性保护算法参数。检查基站的完整性保护算法参数,空算法的优先级为0,高优先级的完整性保护算法都不是空算法,参数配置没有任何问题,见下图：图1-3配置文件完整性保护算法参数由于基站侧完整性保护算法参数没有任何问题,而CDL日志里面,完整性保护算法为空算法,因此怀疑是核心网侧问题,联系核心网侧人员,核心网侧人员答复TAC与LAC对应关系出现问题,导致联合附着失败。处理过程：华为核心网侧人员将TAC与LAC对应关系做了之后,IPHONE5S、5C以及L1在自由选择网络模式下,都可以驻留在LTE网络上。联合附着流程：TD-LTE/TD-SCDMA/GSM<GPRS>多模单待手持终端在给MME发送的附着请求消息中携带支持CSFB能力的指示。MME在收到用户的联合附着请求后,在进行EPS附着的同时,会推导出其相关CS域的VLR信息,并向这个VLR发起位置更新请求,VLR收到位置更新请求以后,会将该用户标记为已经进行EPS附着了,并保存用户的MME的IP地址,这样,VLR中就创建了用户的VLR与MME间的SGs关联。随后,MSCServer/VLR会进行CS域位置更新并把用户的TMSI和LAI<位置区标识>传给MME,从而在MME中建立SGs关联。最后,MME把VLR给用户分配的TMSI以及LAI等信息包含在附着请求接受消息中发送给UE,此时就表明用户的联合附着已经成功了。因此,具有CSFB功能的LTE终端自由模式开机正常流程：优先驻留在LTE,即终端开机—>LTE及2G/3G电路域联合注册〔确保用户同时注册在EPS和GSM电路域网络—>驻留LTE,见图1-4：图1-4联合附着示意图2.4默认网关配置错误问题描述：20XX4月23日车辆在江北环城北路行驶至NB清纯服饰FHTL附近时,发现UE无论是S1、X2均无法从其他站切换至本站进行业务测试,UE显示"无服务"现象,处于脱网状态。待车辆行驶至附近其他基站覆盖区域时,UE重新建立链接,业务测试正常。如下图：问题分析：如上图可见,在NB清纯服饰FHTL-0、-1主覆盖区域RSRP、SINR指标良好〔RSRP-75,SINR7,排除无线环境恶劣导致。查看基站侧发射功率、邻区关系、接入参数、切换参数等均无异常,基站运行状态良好,无告警。查看CDL日志发现,UE也无法从此站接入,UE接入时提示lintialContextsetupFailure〔CAUSETYPEtransport_chosen,如下：查看路由表发现路由表中默认网关配置错误,实际网关应为29,误配置为92。解决措施：修改路由表中默认网关为29。处理效果修改后复测,发现站点NB清纯服饰FHTL接入正常,切换正常,数据下载业务良好。如下:附件或日志：2.5核心网算法问题问题描述：海思E5776终端ATTACH不成功。无法做业务。问题分析：1、原因为网络侧下发NAS层消息指示终端使用EIA0算法,而海思E5776终端拒绝。无线侧信令如下图所示。S1接口抓包信令如下：经核查发现MME在SACKid-downlinkNASTransport,Securitymodecommand中下发的integrityprotectionalgorithm为EIA0<nullintegrityprotectionalgorithm><0>。海思终端回复了SACKid-uplinkNASTransport,Securitymodereject。Securitymodereject消息的详细信息中含有PlainNASmessage,notsecurityprotected<0>,表明未启用安全保护。SACKid-downlinkNASTransport,Attachreject。2、经由排查发现协议规定,空算法一般用于紧急呼叫,普通的业务应该使用snow3g和aes算法,当前诺西核心网的设置为空完整性算法,所以了海思E5776终端拒绝。具体协议规定如下图所示：解决措施：将诺西MME修改IntegrityAlgorithm为AES,修改后参数后的信令如下：在Securitymodecommand消息中,integrityprotectionalgorithm已经改为EPSintegrityalgorithm128-EIA2<2>：在Securitymodecomplete消息中,integrity方式已变为protected。在后续的流程中,完成附着。经验总结：正常的附着流程如下图所示：MME会通过NASSecurityModeCommand消息将完整性算法传送给UE。UE根据NASSecurityModeCommand中选中的算法计算相应的密钥,用于对空口上传输的信令盖一个完整性保护戳,帮助接收端确认收到信令消息的合法性。完整性保护算法是必选的。因协议规定,空算法只能用于紧急呼叫,故MME要下发的完整性算法应该是AES或SNOW3G,而不要下发空完整性算法。2.6信令面流程正常业务面无法上网案例问题描述：2月3日与联谊宾馆进行测试,信令面走到RRC重配置、RRC重配置完成、AttachComplete流程。但是业务面无速率。问题分析：在联谊宾馆站下进行附着接入过程,信令面走到RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、Attach附着完成流程。但是业务面存在问题,无法上网。检查基站配置文件,发现路由关系中网关IP地址配置错误,应该配置为100：67：0：193。实际配置为100：67：0：27。解决措施：将联谊宾馆路由关系修改成100：67：0：193处理效果修改后,业务面正常,上网正常,FTP下载速率稳定在41M〔单通道。2.7三星NOTE23信号标识不显示问题分析案例问题描述：用户反馈三星NOTE2/3一定概率出现不显示数据业务信号格的情况。此时语音业务正常,数据业务中断。问题分析：1问题现象：对比NOTE2和NOTE3出现该问题时的现象和信令图,发现终端从23G模式切换到234G模式后,大约有12S左右无法使用数据业务,终端上的4G信号格不显示4G标识。见图1：NOTE2异常的事件见图2：NOTE2异常的异常信令2协议过程分析：从终端侧看信令：终端在LTE侧进行了RRC请求、建立、完成后,未收到下行传送消息。此时终端上信号格显示的形状也略有不同,NOTE2显示为一个信号格,NOTE3显示为两个信号格,左边为34G模块,只有信号格无信号标识,右边为GSM模块,可正常显示信号标识。由于核心网有时会在15s左右响应NAS层SecurityCommandrequest消息,大唐的RRC连接释放定时器设置为10s,所以这时候终端被异常释放,在4G上未注册成功,从终端表现来看4G信号格不显示4G。图1：NOTE2出现该事件时的表现：图2：NOTE2出现该事件时的表现〔图中出现了一次TAU拒绝,该问题为已知问题承载未建立：对比正常时与出现该异常事件时的信令表现,出现异常事件时,终端发送的ATTACHREQUEST长时间未得到网络侧的相应。从基站侧看：基站向核心网发送了S1直传消息,正常EPC应该下发S1上下文建立请求给基站,但基站在长时间未收到该消息,释放了空口RRC。异常：正常：联系核心网人员,确认该问题由于有链路走的CMNET而不是走IP承载,导致出现几率性丢包情况。核心网提供的信令截图,可以看到从收到终端附着请求到MME去HSS取鉴权集就用了15S,正常只要不到1S。解决措施：针对此问题,核心网已经将出现该事件时的定时器由15S改为6S〔见附图6,由于小于大唐的RRC连接释放定时器,这时用户不会被释放,可缩短用户终端上显示只有信号格的时间。MME取鉴权超时计数器修改后验证,7秒终端可收到下行消息。速率类问题3.1下行子帧调度不满导致平均下载速率低问题分析问题描述：在对晋宁移动LTE网络示范区使用鼎力ATU设备进行拉网时,发现平均速率比较低,拉网结果与华为区域对比如下表：由表中数据可知,我司设备在无线条件均比华为区域好的情况下,FTP下载速率与华为区域相差较大,另外一项比较差的指标为DL平均每秒调度PRB个数,与华为相差13000多个PRB,怀疑此为导致速率低的主要原因。问题分析：FTP下载速率问题分析方法：首先进行无线环境、小区无线参数、基站告警和传输限制等常规检查,在排除这些原因之后,根据速率优化的特点,从以下三方面入手排查速率问题：1CQI与MCS：MCS等级决定了下载速率大小,遇到速率不高的问题,可先检查统计结果中平均MCS等级,若发现MCS等级不高需检查上报的CQI的信道值。CQI主要通过SINR映射,UE上报CQI,基站通过一定策略计算后决定了下行调度的MCS。2MIMO模式：目前外场一般使用TM3和TM7两种模式切换,而我司设备参数值设置是保证双流在TM3上,单流在TM7上。通过统计结果查看双流占比是否合适,如果双流占比不高,则需对转换参数进行优化。3PRB调度是否饱满：PRB调度是否饱满直接影响速率,通过测试数据统计的结果可以看到PRB调度相关的统计值。PRB调度不满可能的原因为网络资源或传输不够导致、系统不用使用那么多PRB就可以传输数据现有的数据。DL平均每秒调度PRB个数如果不满,可能的原因有PRB调度个数/slot不满,测量GAP开启,切换过多导致。问题处理流程：查看无线环境是否良好,从测试指标上看,我们的平均和边缘RSRP和SINR均优于华为区域,因此排除无线环境方面的问题。核查示范区内所有小区无线参数是否正确；方法步骤：查看示范区基站小区是否设置不当,通过查看确定上下行HARQ开关为开、上下行CQI修正开关为开、下行传输模样固定开关为模式间自适应、分配PRB限制开关为不限制、MCS等级限制开关为不限制、下行流控开关为关、下行ICIC开关为关、DRX配置有效指示为关闭,如下图所示：通过核查邻区关系,观察到受限小区都配有D频段异频邻区,于是检查A1、A2、GAP开关状态是否开启,检查结果为A1、A2、GAP均为关闭状态,如下图所示,另外检查信道质量指示参数,如下图所示：检查参数发现参数都是正常的。核查基站设备是否存在告警或基站是否存在故障；通过检查示范区域基站的告警信息,发现测试区域基站无重要告警信息。检查基站传输是否受到限制；通过与局方传输人员沟通确认,晋宁示范区基站传输没有限制,使用的都是千M网口。从示范区单站验证报告来看,各个小区在好点处CAT3终端FTP下载速率都能够达到60M以上。现场也抽验了几个站点,也未发现传输有问题,因此排除传输受限的问题。通过测试统计结果,检查MCS等级,平均MCS等级为19,为比较高的水平。天线模式,双流时长占比为84.29%,所以传输模式也不存在问题。检查PRB调度统计,发现每时隙调度数为97.22,而每秒钟调度PRB个数为95039个,根据计算,每时隙调度97.22个,那么每秒钟应该是：97.22*2*6*100=116664个〔*2：为每子帧；*6：为每帧下行子帧数；*100：每秒调度PRB数,而实际值为95039个,这种情况,只有测量GAP打开,终端进行了异频测量或者是切换过多导致。但是切换的次数总共只有38次,测试的时间有30分钟,所以切换的影响非常小。在上下行子帧配置为1：3,特殊子帧配置为3:9:3的配置下,DL子帧满调度数应该为600,而我们的测试结果为469.3,比满调度少了131次,比华为少了88次。所以推测,是由于测量GAP打开导致子帧调度不满。经过和研发讨论定位如下：每时隙调度满,而每秒钟调度不满,即子帧调度不满,很有可能是测量GAP打开的原因。目前产品实现上,在进行小区切换时,如果目标小区存在异频配置,就会默认配置Gap；如果此时不配置A1,则GaP就一直无法关闭。如存在异频配置,且在拉网测试时不想使用Gap,要么一：将各基站的异频频点和异频邻区都删除〔但会影响异频切换,与室分的切换；要么二：开启A1/A2,按照建议值设置A1/A2,建议A1门限调整到-86dbm,A2门限调整到-90dbm,Gap索引配置为68。问题解决效果：晋宁示范区内D频段站点覆盖过弱,无法覆盖主干道,因此删除异频邻区,删除后复测,发现每时隙PRB调度和每秒钟PRB调度满。总结：根据公司设备的目前版本情况下,GAP开关是无效的,不需要异频切换的小区,建议不添加异频邻区有配置异频邻区的小区,建议按照研发给出的A1/A2和GAP值进行配置。具体如下：测量GAP偏移A1门限A2门限68-86-90附：在测试软件中如何观察调度是否满图中,DCIFormat1aCount或者DCIFormat2aCount值表示5ms调度次数,以上下行子帧配比为2:2,特殊子帧配比为10:2:2为例,其5ms调度PRB应为：3*100=300,因为有3个下行子帧,频域上100个PRB,但调度时,是以PRB对为单位的,因为TTI为1ms。所以300为PRB满调度数目。图中PDCCHDLGrantCount为每秒钟子帧调度次数,每10ms有6个下行子帧,所以1s钟就有6*100次子帧调度,因此,这个计数器的满调度在配置为2:2,10:2:2下,应该为600。3.2传输受限引起的速率问题问题描述：日常单站业务验证期间,发现化工一厂南,下载速率达不到优化标准,环境在SINR=28RSRP=-85COI=14的情况下,下载速率在40M左右,基本没有什么变,图如下：问题分析：分析思路：a>参数配置异常。b>基站是否存在异常告警。b>光模块的大小。d>是否是传输的问题。分析：a>请机房核查,确认一下基本的优化参数,参数正常。b>详细查看基站告警,未发现异常。c>上站查询传输光模块是6G,正常。d>请机房帮忙灌包,开始是先灌60M的包,我在这端通过DUMeter查看和原来下载的速率一样,稳定在40M左右,然后有开始灌30M的包,我在这端通过DUMeter查看和原来下载的速率一样,稳定在30M左右,接着灌40M的包,我在这端通过DUMeter查看和原来下载的速率一样,稳定在40M左右,最后灌45M的包,我在这端通过DUMeter查看和原来下载的速率一样,仍然稳定在40M左右。解决措施：通过和传输人员沟通,修改传输带宽,业务正常。3.3CFI相关设置影响LTE拉网速率分析问题描述：在禄劝县城网格拉网中,ATU测试速率太低。经过分析发现,很多路段,下载速率仅为10M左右。导致此次拉网平均速率不高,平均速率仅为20M。更换华为5776MIFI拉网,速率仅为22M,此次拉网测试存在多处如下问题路段。路测数据分析,该区域属于覆盖良好区域,运政大楼3小区RSRP在-75dBm以上,SINR在17以上,但下载速率仅为6M左右。问题分析：1,查询低速率路段覆盖站点是否存在故障,低速率路段处误码率高不高。经查询站点无故障,低速率路段误码率不高。2,由于ATU拉网测试无法看到实时调度情况,统计此次拉网本次测试本次测试每秒调度PRB个数87616.5703,下行子帧调度率392。怀疑当时服务器出问题,或是测试设备异常。通过复测定位问题。更换测试设备拉网测试,分析是否为设备问题,此次定位更换为华为5776MIFI；使用30线程拉网,分析是否为服务器问题。3,使用华为5776拉网,拉网过程中查看实时调度情况,发现ATU测试低速率路段,使用MIFI测试速率仍然在10M以下,排除设备问题。而拉网过程中仍然有高速率路段,调度600,说明服务器没有问题。本次测试中仍然存在如下低速率路段,测试发现在这些路段主服务小区下,调度太少均在100多。如下运政大楼3小区覆盖路段和锦绣家园1小区覆盖路段：4,小区下定点测试,复位站点,发现复位起来后一段时间内下载正常,但是1小时以后再查看,发现问题复现。5,查看这些小区下用户数,发现均存在较多用户,选取一个用户数较少的小区进行定点测试,选择彝城新都灯杆1小区,该小区下存在1-2个用户。测试速率仍然不理想。怀疑此时为多用户同时下载导致调度低,速率低。选择凌晨1点对该小区进行测试发现调度问题仍无改善,调度仅为100多,速率仍然在10M左右。6,怀疑多用户引起调度不足问题,查看调度相关参数。此时的设置时：专用搜索空间聚合等级为8CCE,上下行都发PDSCH控制符号数为2,下行发PDCCH时域控制符号数为1。尝试修改上下行都发PDSCH控制符号数配置为3,下行发PDCCH时域控制符号数为2时,调度和速率正常。解决措施：从上述分析,得知本次低速率问题是由于：专用搜索空间聚合等级为8CCE,上下行都发PDSCH控制符号数为2,下行发PDCCH时域控制符号数为1。按照目前cce为8的设置,单个子帧上下行同时调度,只能调度1个用户。除非能够保证小区内就一个用户在做业务。否则速度很低。从上述验证情况看：专用搜索空间聚合等级配置为8CCE,上下行都发PDSCH控制符号数配置为3,下行发PDCCH时域控制符号数为2时,调度能接近600满调度,下载速率正常;将全网改为：专用搜索空间聚合等级配置为8CCE,上下行都发PDSCH控制符号数配置为3,下行发PDCCH时域控制符号数为2。处理效果测试中低速率路段,调度低问题解决,下载速率提升明显。5线程MIFI拉网速率为32M。运政大楼3小区拉网测试速率改善：锦绣家园1小区拉网测试速率改善：CSFB类问题4.1UE未收到Release消息重选到TDS问题描述：XX市莲都区移动公司,通过两部iPhone5s互拨发现主,被叫均出现概率性回落到3G的情况。通过鼎力软件分析发现终端在发起Extendedservicerequest后没有收到rrcconnectionrelease消息,之后重选到3G。下图所示为主叫收到rrcconnectionrelease消息重选到3G。问题分析：提取该时段CDL日志发现基站侧向UE发起rrcconnectionrelease消息〔携带了G网频点信息。如下图所示：查看小区状态均正常,无上行干扰,通过去激活激活小区操作无效；通过与正常站点的参数核查对比,最后发现LTE服务小区D780401莲都移动大楼分布E-2〔PCI：1的DRX功能开启指示为"打开",而DRX配置信息中DRX配置有效指示为"关闭"。对比D780401莲都移动大楼分布E-1小区,DRX功能开启指示为"打开",DRX配置信息中DRX配置有效指示为"打开"；将D780401莲都移动大楼分布E-2小区修改DRX参数配置信息与D780401莲都移动大楼分布E-1小区相同,主要修改DRX配置有效指示为：开启、激活定时器时长：6调整为8、非激活定时器时长10调整为60、重传定时器时长：8调整为4、长DRX周期调整为160,CSFB就不再回落到3G。服务小区修改DRX参数基站配置信息前,如下图