TD-LTE网络优化案例汇总.doc

TD-LTE网络优化案例汇总项目名称文档编号版 本 号部 门专业服务业务部作 者版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。目 录1.切换类问题21.1邻基站信息未配置成功21.2 X2口不通导致的切换失败41.3硬件和传输故障61.4随机接入参数配置不当引起切换失败71.5重选优先级设置不一致导致异频无法切换111.6 MME问题导致入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失败641. 切换类问题1.1邻基站信息未配置成功问题描述：测试发现NBHS维科上院FHTL-1 PCI=487与NBHS青林湾西FHTL-0 PCI=438之间切换失败。从前台测试LOG可以看出，18:10:8.533占用NBHS维科上院FHTL-1 PCI=487上报MR，目标小区NBHS青林湾西FHTL-0 PCI=438，没有响应，18:10:50. 42秒后上报第2个MR。两个小区的位置图层：问题分析：ATP抓包反馈情况：第一个MR没有反馈：第二个MR，启动切换，但是切换准备失败，反馈传输资源不足造成，最后还是完成切换，前台测试切换至NBHS锦江年华FHTL-2 PCI=320非NBHS青林湾西FHTL-0 PCI=438。查看导出的邻区关系列表，NBHS维科上院FHTL-1 PCI=487与NBHS青林湾西FHTL-0 PCI=438两个小区之间存在邻区关系，但是查看配置文件，发现青林湾西邻基站中未配置维科上院的邻基站信息（200914与200894）。解决措施：添加青林湾西邻基站中未配置维科上院的邻基站信息。处理效果添加两个基站之间的邻基站信息后，小区间切换支持。附件或日志：1.2 X2口不通导致的切换失败问题描述：测试车辆由南向北行驶至前湖北路路段，UE占用NBYZ四季瑞丽1小区PCI483的信号，在该路段接收到主服小区的RSRP-106dBm，无线信号在该路段覆盖较差。通过UE上报的测量报告发现，UE有上报切换目标为NBYZ现代轿车城3小区PCI473，该小区的RSRP-88dBm，信号良好；但未发生切换。无线覆盖示意图测量报告示意图邻区关系示意图问题分析：测试车辆由南向北行驶至前湖北路路段，UE占用NBYZ四季瑞丽1小区PCI483的信号，在该路段接收到主服小区的RSRP-106dBm，无线信号在该路段覆盖较差。通过UE上报的测量报告发现，UE有上报切换目标为NBYZ现代轿车城3小区PCI473，该小区的RSRP-88dBm，信号良好；但未发生切换，经核查邻区发现NBYZ四季瑞丽1小区与NBYZ现代轿车城3小区之间未添加邻区关系。解决措施：添加这两个小区邻区关系之后仍不切换，检查小区状态，状态运行正常，无故障。随后检查这两个小区的X2接口连接指示发现，配置状态为“不存在”，修改为“存在”后，切换正常。处理效果把X2接口连接指示配置状态修改为”存在后“切换正常。1.3硬件和传输故障问题描述:5月27日，蒋王庙试扩L 329138,00蒋王庙试扩L-2_2站内切换指标如下：服务小区名称服务小区IDeNodeB内切换出成功次数eNodeB内切换出尝试次数eNodeB内切换出失败次数ENODE内切换成功率蒋王庙试扩L 329138,00蒋王庙试扩L-2_2329138911281.82%32913856183.33%32913856183.33%32913846266.67%从KPI的统计表中可以看出，基站内切换成功率在一段集中的时间内较差，而之前的时间段ENB内切换成功率均为100%。问题分析：根据下图上午MR计算出目标小区的RSRP为-90dBm，覆盖良好。1.4随机接入参数配置不当引起切换失败问题描述：使用L1*Outum8.0进行测试时候发现云南昆明LTE网络新入网很多基站在无线环境很好（RSRP-80dbm左右&SINR20左右）的情况下基站内小区间切换均失败，在测试中时出现以下情况，UE在正常接入小区后，UE上发测量报告，然后基站下发重配置消息，UE上传重配置完成消息，从无线口信令消息看切换已经完成。但是从测试过程中发现并没有切换成功，而是经过2秒后基站下发MIB消息、系统消息，然后 UE上传连接重建消息，接着基站下发连接重建命令，UE上传连接重建完成，到此UE应该是重新接入小区，并不是切换。具体个例如下：同时在基站侧用ATP进行跟踪时，出现如下图情况：UE上传测量报告，基站下发连接重配置消息，但UE在2秒内无回应或者基站在这2秒内没收到重配置完成消息，于是2秒之后UE上传系统消息1，而基站则下发系统消息2，然后就是上传连接重建请求消息，基站下发连接重建命令，接着 UE上传连接重建完成，到此UE重新接入小区问题处理流程：1、首先针对小区内邻区进行检查，邻区配置正确；2、由于是双模站点，所以提取同样为双模站点的宁波参数进行对比，发现关于切换的参数均配置正确；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链路故障的告警。如果由于小区重复退服，可能导致站内切换成功率下降。告警名称告警级别告警源网元类型产生时间小区退服,传输故障主要蒋王庙试扩L 329138,小区 2ENB2013-05-27 20:38:16X2链路故障次要蒋王庙试扩L 329138,SCTP链路 2ENB2013-05-27 20:02:05小区退服,传输故障主要蒋王庙试扩L 329138,小区 2ENB2013-05-27 19:28:36问题解决：安排基站人员上站排查，重现建立X2链路后告警消除。解决效果：28日现场排除告警后提取当日指标进行验证。下表为蒋王庙28日全天级指标，已有明显提升。服务小区名称服务小区IDeNodeB内切换出成功次数eNodeB内切换出尝试次数eNodeB内切换出失败次数ENODE内切换成功率蒋王庙试扩L 329138329138261264398.86%1.5重选优先级设置不一致导致异频无法切换问题描述：云南昆明LTE实验网新开局对室内和宏站之间异频切换进行验证。使用L1*Outum8.0/华为MIFI*Outum8.0进行异频切换验证；验证参数配置： 1、X2链路、邻区关系与小区异载波信息配置完成；2、A1 A2算法均开启测量；3、GAP测量打开；从验证结果发现室分可以切换到宏站，而从宏站无法切换到室分；问题分析：在进行切换验证测试时发现当师大商学院（宏站）的RSRP值达到-112dbm且嵩明云南师范大学商学院动感厅（室分）的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.6 MME问题导致入POOL基站大量切换失败问题描述：福州KPI组发现3月8日后全网的切换成功率一直在恶化，提取切换失败TOP小区分析CDL发现，切换失败大部分为目标小区回复切换准备失败携带原因为transport-resource-unavailable。问题分析：在基站版本45.16版本升级后，福州全网也出现了大量的切换失败，失败原因为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的切换有成功的，于是对比时间相近的切换失败和切换成功。通过对比x2 Handover Request的IE值，发现切换成功时该消息拾的GUMMEI中MME-CODE为D0H（208）对应福州MME，而切换失败时的MME-CODE都为10H(16)对应厦门MME。在OMC上查看418705的S1链路状态，发现到福州MME的S1链路状态为“与对端连接成功”（正常），而与厦门MME的S1链路状态为“驱动建立成功”（故障）。再分析目标基站418644的CDL日志，发现该站有大量的S1建立失败信令，检查S1 Setup Request的各IE值都正常，S1 Setup Failure携带原因为message-not-compatible-with-receiver-state。为区分是基站问题还是MME问题，分别删除再添加该站到厦门和福州的MME，到福州MME的S1链路马上建立成功，到厦门MME的S1链路仍然故障。对比基站给两个MME发送的S1 Setup Request的IE值完全一致，说明基站的S1 Setup Request消息并没有问题，问题出在厦门MME上。分析剩余的TOP小区，发现都存在与418705一致的现象，即目标小区到厦门MME的S1链路故障。目前福州全网基站已开启S1-FLEX算法，全部入MME POOL(福州、厦门两台MME)，且两台MME的能力都配置为50，为负荷分担方式组网，所以正常入POOL的基站下接入，UE有50%的概率接入到两台MME上。通过信令和TS36.413我们可以知道，ENB发起S1 Setup Request，MME回复S1 Setup Response会携带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回复Handover Preparation Failure，导致切换失败。解决措施：在分析出是厦门MME问题导致全网切换失败后，联系厦门MME人员，提供S1建立失败的基站信息，MME侧抓包、提取MME日志确认是MME的问题。只要MME处理完后基站S1正常建立，切换成功率即可恢复。虽然切换成功率恶化的原因已查明为MME故障，但是在定位过程中基站给出的切换准备失败的Cause值误导了现场的问题定位。对于目标S1链路故障导致切换准备失败的现象，在和NSN,ZTE跨厂家切换的时候已经分析过，但是对于这类问题，其他厂家一般在Handover Preparation failure中携带的原因为“Unknown MME Code”，而我们基站是回复“transport-resource-unavailable”，影响了问题的定位效率，而TS36.423中对这类原因有注释，其他厂家此类问题的原因归类为“Unknown MME Code”更能有效指导问题定位。与研发确认，目前基站版本eNB只是发现用户所在的Gummei与自己连接的MME不一致，直接判断失败。并没有进一步判断是GroudID不正确，Plmn不正确，还是Mme Code不正确。为便于容易指导现场定位，后续基站版本会加入相应判断，优化Cause值。处理效果：3月15日凌晨，厦门MME人员针对S1无法建立的问题现场处理后，原因到厦门MME的S1链路故障的全部恢复正常，当天全网的切换成功率就回升到95%。1.7开站数据模板不对引起切换失败问题描述：近日新开LTE室VIP站点泗阳移动公司新大楼，添加完邻区后状态正常，现场发现无法切换到室外宏站，但是室外宏站可以切换到室内，随后对该问题进行分析定位。问题分析：1、 无线环境分析CellNameECITACBandWidthFrequency_DLPCI宿迁泗阳移动新大楼LEW-1020559202360500宿迁泗阳新世界LF-102055920189084根据现场测试，宿迁泗阳移动新大楼室外最强宏站为泗阳新世界LF-1，RSRP电平在-90-100之间，相对较弱，但根据小区算法-切换算法-邻小区RSRP门限为20（-120dbm），室外电平满足切换入的要求。2、 信令分析1）、通过前台新令分析，在由室内到室外过程中，UE发送MR后收到RRC释放请求，并没有进入RRC 重配过程，如下图：从后台上看为收到测量报告后，eNB向EPC侧发送 UE Context Release Request 释放上下文，同时向UE发送RRC释放，最终无法完成切换。 分析eNB释放上下文携带的原因为ue-not-aivilble-for-ps-service,该原因与CSFB重定向到2G的原因一致，对RRC Connection Release进行分析，发现携带GERAN频点信息，初步判断为进入了盲重向过程，而没有进行异频信息测量。2）、现场随后进行参修改，关闭小区-小区测量-A3事件配置1.1-测量相关算法中的小区间干扰协调算法，同时将A1和A2 RSRQ门限值都修改为-50，现场测试发现UE一直上发测量报告，但无法收到携带异频（38350）的RRC重配置消息，导致终端一直无法进行异频测量，该问题为现场将A1/A2设置一致导致异频测量无法启动。3）、现场将GERAN异载波信息、GERAN邻小区关系删除，同时将A2 RSRP门限值修改为-90，同时关闭A1事件配置（关闭A1事件配置为更换定位问题，终端始终开启异频测量），测试发现能够正常进行切换。 4）、后台重新将GERAN异载波信息、GERAN邻小区关系添加后测试，又再现RRC释放，现象和之前一样，判断为添加GERAN异载波信息后上报本小区电平测量达到一定的门限，触发了盲重定向过程，而该过程门限高于异频切换门限，导致在室内到室外移动过程中，室内信号渐弱，在室外电平未满足切换之前发生了盲重定向，释放RRC，其中A2 RSRP门限、系统间测量门限、和盲重定向门限设置如下 当时无线环境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切换成功率低问题描述： 临汾两站之间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，例如 ping 9 -s 200 -c 10 【-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 Thresh A2事件的触发条件：Ms + Hys -98 MS-96 dBm 时停止异频异系统测量A2:MS+2-100 MS=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. 接入类问题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建立失败问题描述：福州在海峡会展保障期间出现大量ERAB建立失败，18:0019:00，E-RAB失败2100次，严重影响全网指标，造成用户感知较差。 问题分析：查看CDL：核心网在发起S1 Initial Context Setup Request，之后AP侧上报两次AP_PER_ERROR，基站直接回复S1 Initial Context Setup Failure,失败原因为semantic-error定位过程：经过查看核心网发出的上下文建立请求消息中，发现AMBR携带的值为0，根据协议，eNB判断此消息非法，会导致上下文建立失败，影响上下文建立和承载建立的KPI。现场和诺西的核心网厂家确认，此问题为诺西EPC的已知BUG。具体协议如下：0 UE Aggregate Maximum Bit RateThe UE Aggregate Maximum Bitrate is applicable for all Non-GBR bearers per UE which is defined for the Downlink and the Uplink direction and provided by the MME to the eNB.IE/Group NamePresenceRangeIE type and referenceSemantics descriptionUE Aggregate Maximum Bit RateApplicable for non-GBR E-RABs.UE Aggregate Maximum Bit Rate DownlinkMBit Rate 9This IE indicates the UE Aggregate Maximum Bit Rate as specified in TS 23.401 11 in the downlink direction.UE Aggregate Maximum Bit Rate UplinkMBit Rate 9This IE indicates the UE Aggregate Maximum Bit Rate as specified in TS 23.401 11 in the uplink direction. Receiving both the UE Aggregate Maximum Bit Rate Downlink IE and the UE Aggregate Maximum Bit Rate Uplink IE equal to value zero shall be considered as a logical error by the eNB.定位结果：现场将此问题呈现给诺西厂家，希望能尽早解决此BUG。KPI指标目标目前已恢复正常。2.3LTE多模终端自由选择网络不能接入LTE网络问题分析问题描述：IPHONE 5S和L1终端在自由选择网络模式下，无法驻留在任何网络。在手机上看，是手机显示LTE网络，或者2G/3G网络，但是不能进行任何业务，打电话和上网。而且信号格显示是空的，即没有信号。而IPHONE 5S和L1终端终端在华为的站点下，是可以正常驻留并进行CSFB业务的。L1终端选择仅LTE模式下，可以正常接入LTE网络，并且进行数据业务。使用HISI E5776测试此站点，无任何功能性问题，可以接入，业务正常。将IPHONE 5S在问题站点下重新开关机，提取基站CDL日志，从CDL日志的信令流程来看，信令走到了SecurityModeCommand就释放了，见下图：图1-1 IPHONE 5S开机CDL信令流程点开SecurityModeCommand，里面的详细内容见下图：图1-2 SecurityModeCommand消息内容问题分析：1、一般接入问题需要检查站点配置文件中的接入参数、TAC、IP地址和路由关系等参数设置。本案例中，使用L1和E5776可以正常接入网络并且进行数据业务，说明基站侧接入参数、TAC、IP地址和路由关系都没有问题。2、商用终端的完整性保护算法不能为空算法，这在早期的网络优化过程中也遇到一些商用终端不能接入LTE网络的问题，后来都是通过修改完整性保护算法优先级来解决。3、对于有CSFB功能的LTE终端来说，联合附着不成功，会导致终端不能驻留在LTE网络。典型的CSFB业务流程主要包括联合附着、位置更新、主叫(MO)CSFB流程、被叫(MT)CSFB流程以及去附着等。 启用CSFB功能的用户的附着流程是基于联合GPRS/IMSI附着流程来实现的。问题处理流程：1、 由于CDL日志里面，完整性保护算法为eia0，即为空算法，导致终端不能接入。因此需要检查基站侧的完整性保护算法参数。检查基站的完整性保护算法参数，空算法的优先级为0，高优先级的完整性保护算法都不是空算法，参数配置没有任何问题，见下图：图1-3 配置文件完整性保护算法参数2、 由于基站侧完整性保护算法参数没有任何问题，而CDL日志里面，完整性保护算法为空算法，因此怀疑是核心网侧问题，联系核心网侧人员，核心网侧人员答复TAC与LAC对应关系出现问题，导致联合附着失败。处理过程：华为核心网侧人员将TAC与LAC对应关系做了之后，IPHONE 5S、5C以及L1在自由选择网络模式下，都可以驻留在LTE网络上。联合附着流程：TD-LTE/TD-SCDMA/GSM(GPRS)多模单待手持终端在给MME发送的附着请求消息中携带支持CSFB能力的指示。MME在收到用户的联合附着请求后，在进行EPS附着的同时，会推导出其相关CS域的VLR信息，并向这个VLR发起位置更新请求，VLR收到位置更新请求以后，会将该用户标记为已经进行EPS附着了，并保存用户的MME的IP地址，这样，VLR中就创建了用户的VLR与MME间的 SGs关联。随后，MSC Server/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默认网关配置错误问题描述：2013年4月23日车辆在江北环城北路行驶至NBJB清纯服饰FHTL附近时,发现UE无论是S1、X2均无法从其他站切换至本站进行业务测试，UE显示“无服务”现象，处于脱网状态。待车辆行驶至附近其他基站覆盖区域时，UE重新建立链接，业务测试正常。如下图：问题分析：如上图可见，在NBJB清纯服饰FHTL-0、-1主覆盖区域RSRP、SINR指标良好（RSRP-75，SINR7），排除无线环境恶劣导致。查看基站侧发射功率、邻区关系、接入参数、切换参数等均无异常，基站运行状态良好，无告警。查看CDL日志发现，UE也无法从此站接入，UE接入时提示lintial Context setup Failure（CAUSE TYPE transport_chosen），如下：查看路由表发现路由表中默认网关配置错误，实际网关应为29，误配置为92。解决措施：修改路由表中默认网关为29。处理效果修改后复测，发现站点NBJB清纯服饰FHTL接入正常，切换正常，数据下载业务良好。如下: 附件或日志：2.5核心网算法问题问题描述：海思E5776终端ATTACH不成功。无法做业务。问题分析： 1、原因为网络侧下发NAS层消息指示终端使用EIA0算法，而海思E5776终端拒绝。无线侧信令如下图所示。S1接口抓包信令如下：经核查发现MME在SACK id-downlinkNASTransport, Security mode command中下发的integrity protection algorithm为EIA0 (null integrity protection algorithm) (0)。海思终端回复了SACK id-uplinkNASTransport, Security mode reject。Security mode reject消息的详细信息中含有Plain NAS message, not security protected (0)，表明未启用安全保护。SACK id-downlinkNASTransport, Attach reject。2、经由排查发现协议规定，空算法一般用于紧急呼叫，普通的业务应该使用snow3g和aes算法， 当前诺西核心网的设置为空完整性算法，所以了海思E5776终端拒绝。具体协议规定如下图所示：解决措施：将诺西MME修改IntegrityAlgorithm为AES，修改后参数后的信令如下：在Security mode command消息中，integrity protection algorithm已经改为 EPS integrity algorithm 128-EIA2 (2)：在Security mode complete 消息中，integrity方式已变为protected。在后续的流程中，完成附着。经验总结：正常的附着流程如下图所示：MME会通过NAS Security Mode Command 消息将完整性算法传送给UE。UE根据NAS Security ModeCommand中选中的算法计算相应的密钥，用于对空口上传输的信令盖一个完整性保护戳，帮助接收端确认收到信令消息的合法性。完整性保护算法是必选的。因协议规定，空算法只能用于紧急呼叫，故MME要下发的完整性算法应该是AES或SNOW3G，而不要下发空完整性算法。2.6信令面流程正常业务面无法上网案例问题描述：2月3日与联谊宾馆进行测试，信令面走到RRC重配置、RRC重配置完成、Attach Complete流程。但是业务面无速率。问题分析：在联谊宾馆站下进行附着接入过程，信令面走到RRCConnectionReconfiguration、RRCConnectionReconfigurationComplete、Attach附着完成流程。但是业务面存在问题，无法上网。检查基站配置文件，发现路由关系中网关IP地址配置错误，应该配置为100：67：0：193。实际配置为100：67：0：27。解决措施：将联谊宾馆路由关系修改成100：67：0：193处理效果修改后，业务面正常，上网正常，FTP下载速率稳定在41M（单通道）。2.7三星NOTE23信号标识不显示问题分析案例问题描述：用户反馈三星NOTE2/3一定概率出现