TD-LTE网优KPI指标优化指导手册(共89页).doc

《TD-LTE网优KPI指标优化指导手册(共89页).doc》由会员分享，可在线阅读，更多相关《TD-LTE网优KPI指标优化指导手册(共89页).doc（89页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上TD-LTE网优KPI指标优化工作指导手册项目名称文档编号版 本 号作 者版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。文档更新记录日期更新人版本备注2013-7-17王学斌V0.0.1创建2013-7-31王学斌 卢颢V0.0.2添加RRC、ERAB、掉线CDL信令流程及失败原因2013-9-20王学斌、张发厚、索志刚、魏晓东、闫俊霖、徐世

2、勋V0.0.3编写案例2013-9-29徐世勋V0.0.4增加章节2.KPI优化的工作流程及内容2013-10-23王学斌、周晓华、王会庆V0.0.5增加案例2013-10-24徐世勋V0.0.6汇总及增加KPI问题处理工单模板2013-11-5徐世勋V0.0.7根据评审意见进行修改2013-11-8童志坚V0.0.8增加童志坚整理的案例：3.5.2小区上行功控参数设置问题目 录1 前 言话统KPI是中国移动考核项之一，也是对网络质量的最直观反映。日常话统监测是进行网络性能检测的一种有效手段。通过日监测，识别突发问题小区，将问题消除在初级阶段。通过周监测，识别网络性能持续短木板小区，针对性的进

3、行提升优化。话统KPI主要包括以下几大类：接入性指标、保持性指标、移动性指标、业务量指标、产品运行类指标、系统可用性指标和网络资源利用率指标。通过上述重点话统KPI指标的监测，可以达到：识别突发问题、风险提前预警、话统KPI的稳定与提升，目前TD-LTE系统需要重点关注的话统KPI指标如下表：指标分类数据来源具体的KPI指标接入性指标无线侧RRC连接建立成功率ERAB建立成功率无线接通率保持性指标无线掉话率（ERAB异常释放）移动性指标小区eNodeB内切换出成功率小区eNodeB间切换出成功率业务量指标上、下行业务平均吞吐量量上、下行PRB平均利用率产品运行类指标无线侧单板CPU最大占用率单

4、板CPU平均占用率系统可用性指标无线侧无线网络退服比例网络资源指标无线侧上行PRB资源使用的平均个数下行PRB资源使用的平均个数2 KPI优化的工作流程及内容2.1 KPI优化工作总体流程KPI优化工作流程图2.2 KPI优化工作内容2.2.1 KPI数据生成工作内容：使用预定义和自定义的统计项及模板生成KPI性能报表，通过OMC Client提取KPI报表，输出KPI报表和重要指标失败原因列表给KPI数据分析人员。KPI报表生成和提取相关操作请参考LTE KPI模板指导手册。根据KPI报表数据，选择KPI指标最差Top N小区。TOP N小区的选择：对某项指标按照失败率最高进行排序，选取前2

5、0个小区，再对这20个小区进行失败次数分析，失败次数大于20次的（RRC连接、切换、掉线等按失败次数大于20次为标准，ERAB建立失败指标按次数大于10次为标准）作为TOP小区进行分析；另外需要对指标再进行失败次数的降序排序，如果有小区失败次数很多失败率也较高但是未在之前选的TOP小区中，也需要将这些小区作为TOP小区分析。 KPI数据生成工作所需输入、工具和技术、输出如图所示：2.2.2 KPI数据分析工作内容：KPI指标变化趋势分析：根据KPI报表数据，分析全网KPI指标变化趋势，尤其是存在设备版本升级或参数全网性修改后，需要持续至少一周重点监测KPI指标变化趋势；TOP小区分析：根据TO

6、P小区列表、重要指标失败原因列表、历史告警信息、网管数据、CDL日志、IOT数据、复测终端LOG等信息进行分析。先查看告警信息，确认有设备故障类告警是否和TOP小区关联，再使用与基站软件版本匹配的CDLBrowser工具进行指标统计和失败信令流程分析确认TOP小区产生的原因，CDLBrowser工具使用方法请参考CDL分析工具使用手册。 KPI数据分析工作所需输入、工具及技术、输出如图所示： 2.2.3 问题处理工作内容：1）通过CDL分析能够明确定位TOP小区问题后，给出问题处理建议输出给相关问题处理人员：参数修改问题导给维护人员调整（和标定参数不一致的大规模参数修改需和SE确认）；网络优化

7、问题给出优化建议导给网优人员；由于设备故障引起的KPI指标恶化问题导给排障人员处理；定位确认为产品缺陷要及时提交BUG推动和跟踪版本解决。2） 通过CDL分析无法明确定位TOP小区产生原因的问题，需要复测后结合终端侧log再进一步分析。 问题处理工作所需的输入、工具及技术、输出如图所示： 问题处理：输入、工具及技术、输出2.2.4 问题跟踪和核查工作内容：问题跟踪和核查环节，主要依据问题列表、KPI问题处理工单、BUG/CR/RR编号，内部讨论推动和核查问题解决，和外部其它环节沟通确认问题进展，以形成问题闭环，最终输出KPI优化报告。问题跟踪和核查工作所需的输入、工具及技术、输出如图所示：问题

8、跟踪和核查：输入、工具及技术、输出2.3 KPI优化工作逻辑图 综合KPI优化工作流程和内容，KPI优化工作逻辑图如下：KPI优化工作逻辑图2.4 KPI优化工作模板和示例1. KPI优化工作参考模板 KPI报表示例 3 RRC连接建立成功率优化3.1 理论介绍RRC连接建立过程分为两个阶段：准备阶段和实施阶段。在准备阶段中，UE会根据NAS 层的触发原因和系统广播中的接入限制信息，通过一系列检查来判断自己是否被允许进行接入过程，如果可以，则执行后续的实施阶段；否则UE的RRC将启动相应的定时器，在该定时器超时前UE无法发起任何接入过程。上述机制的目的是负荷拥塞控制，当网络负荷较重时限制某些U

9、E进行接入。3.2 指标定义RRC连接建立是指处于空闲状态的UE或待开机的UE准备发起一个呼叫或响应寻呼时发起的过程。出于降低接入时延的考虑，LTE系统将RRC连接建立过程设计发生在ENB和MME之间的S1连接建立前，也就是在ENB尚未从MME获得任何UE上下文前，ENB需要将RRC连接建立完毕，因此该过程主要建立最基本的SRB1。RRC连接建立成功意味着UE与网络建立了信令连接，是进行其他业务的基础。RRC连接建立成功率主要通过话务统计结果获得，推荐的公式为：RRC建立成功率= RRC连接建立完成次数/RRC连接请求次数（不包括重发）；公式中相关各指标的具体统计方式如下所示：指标指标描述RR

10、C连接请求次数小区接收UE的RRC Connection Request消息次数（不包括重发）RRC连接建立完成次数小区接收UE返回的RRC Connection Setup Complete消息次数RRC建立失败次数资源分配失败而导致连接建立失败的次数UE无应答而导致连接建立失败的次数小区发送RRC Connection Reject消息次数3.3 CDL信令流程及失败原因3.3.1 正常过程图RRC建立过程正常流程每当在CDL log中发现一条UU接口RRC Connection Request消息时，代表某一个UE连接建立的开始，此后所有的消息都可以提取相同的CellUeIndex和CE

11、LL ID。当看到RRC Connection Setup和RRC Connection Setup Complete消息时，标志着RRC建立正常流程的结束。3.3.2 异常过程i. RRC连接建立完成超时图RRC连接建立完成超时每当在CDL log中发现一条UU接口RRC Connection Request消息时，代表某一个UE连接建立的开始，此后所有的消息都可以提取相同的CellUeIndex和CELL ID。当看到UU接口的RRC Connection Setup和RRC事件类接口的RRC_OVERTIME消息，并且第3条消息的定时器类型字段为RAC_TIMER_W_RRC_SETUP

12、_CMPLT时，标志着RRC连接建立完成超时。ii. RRC连接建立拒绝图RRC连接建立拒绝每当在CDL log中发现一条UU接口RRC Connection Request消息时，代表某一个UE连接建立的开始，如图2.10所示。第1、2条消息为UU接口的RRC Connection Request、RRC Connection Reject，2条消息有相同的小区标识与UeIndexCell，是连接建立发生时基站为UE新分配的索引。3.4 优化方法介绍LTE系统内RRC连接建立失败问题的可能原因大概分为如下几条：RRC建立失败主要的原因有：上行随机接入信道功率问题、小区重选参数问题、下行初始发

13、射功率偏低、上行初始功控问题、拥塞问题或设备异常问题等。当出现RRC连接建立成功率低的问题时，首先按照上述问题分类，了解相关问题的范围，然后根据空口信号质量、参数配置、干扰和上下行功率调整及设备告警等方面入手逐一排查解决，排除这些影响RRC连接建立成功率的客观因素，逐步提升该指标的成功率。 RRC连接建立的过程主要包括以下3个个步骤：RRC连接建立成功信令流程（1）首先UE通过SRB0发送RRC Connection Setup Request消息（注： SRB0一直存在， 用来传输映射到CCCH 的RRC信令。）此消息主要携带UE初始（NAS）表示以及该连接建立的原因等信息， 此高层消息会触

14、发UE的底层试题进行基于竞争的随机接入过程，RRC连接建立请求消息就对应于底层随机接入过程中的Msg3（2）通过底层的竞争接入冲突解决机制，UE接收到ENB的RRC Connection Setup消息，建立了UE与ENodeB之间的SRB1，NodeB为SRB1配置RLC层和逻辑层信道的属性。ENB还在此信令中对PHY /MAC/RLC /PDCP 等各个实体的配置参数进行配置， RRC连接建立消息就对应于底层随机接入过程中的Msg4。UE收到NodeB的rrcConnectionSetup信令后，UE和ENB 之间的SRB1就建立起来了。 （3）在UE接收到RRCConnectionSet

15、up消息后，向ENB 发送一个RRC Connection Setup Complete消息。此消息中携带有上行方向的初始NAS层的信令消息（如Attach Request，TAU Request，Service Request等），ENB收到此消息后，将其中的NAS消息转发给MME用于建立S1连接。 在第（2）步中，如果ENB拒绝为UE建立RRC连接，则通过SRB0回复一条RRC连接拒绝消息RRC Connection Reject。在该RRC连接拒绝消息中，网络侧可以可选地携带一个禁止呼叫的定时器T302，该定时器和系统广播中的接入限制信息共同决定了UE是否被允许发起接入过程。 一般RRC

16、连接建立问题的定位方法如下，通用流程：RRC连接建立问题N设备异常问题UE是否发出请求消息Y调整随机接入上行初始接收目标功率相关参数ENB是否收到请求消息NYNENB是否发出建立消息ENB相关其他问题YUE是否收到RRC建立消息NN是否发生小区重选调整下行公共信道功率YY优化小区重选参数UE是否发出RRC建立完成消息N调整下行初始发射功率Y调整上行专用信道开环功控参数NENB是否收到建立完成消息Y3.4.1 上行随机接入的问题UE发出RRC Connection Request消息，ENB没有收到，如果此时的下行信道质量正常，一般是随机接入参数中的初始接收目标功率设置偏低的问题。 3.4.2

17、小区重选参数问题ENB收到UE发的RRC建立请求消息后，下发了RRC Connection Setup消息而UE没有收到。查看此时的SINR，如果偏低，而且监视集中没有质量更好的小区，那么是覆盖的问题可以适当提高下行公共信道的功率。如果此时监视集中有更好的小区，则可能是小区重选的问题，可以适当调整小区重选参数加快小区重选。 3.4.3 下行初始发射功率偏低问题 UE收到RRC Connection Setup消息而没有发出RRC Connection Setup Complete消息，如果此时下行的信号质量正常，那么可能是手机异常，否则可能是下行初始功率过低导致下行不能同步。 3.4.4 上行

18、初始功控问题 UE发出RRC Connection Setup Complete消息而ENB没有收到，由于上行初始功控会让UE的发射功率上升，如果是UE的发射功率不足导致，可以适当提高上行信道的初始期望功率和调整量等参数。3.5 相关案例介绍分析3.5.1 小区重选参数问题问题描述：华电集团专项2小区接入率很低，且主要集中在15点到16点之间，查看小区无告警。由于接入失败次数过多，影响全网一天的KPI指标数据。问题分析：从CDL信令看UE发起随机接入申请，UE发出RRCConnectionRequest后 ENB下发RRC connection setup 消息，终端无响应，造成RRC连接建立

19、完成超时，导致RRC建立失败。定位过程：从最近一次的测量上报消息中可以看出，源小区PCI为254，此时测量到的rsrpResult 值为23，由此可以计算出RSRP的值为23-141=-118dbm左右。而测量到的相邻目标小区PCI为62 ，rsrpResult值为34，小区RSRP在-107dbm左右。由此可以初步分析相关的场景是UE所处位置的信号质量不好，且存在模3干扰，最终导致RRC连接建立定时器超时后RRC连结建立失败。解决建议：查看基站配置后，该小区的参考信号功率为15，已经为最大。故不存在下行初始发射功率偏低问题。通过现场复测抓取log进一步分析，排除天线安装问题以及工参设置问题、

20、排除存在大面积的弱覆盖问题。通过log分析，发现存在PCI模三干扰严重，重新进行规划，修改小区的PCI。解决效果：修改PCI后，RRC接入率有所提，KPI指标数据恢复正常。3.5.2 小区上行功控参数设置问题问题现象 NBYZ技侦大楼FHTL-0从7月13日开始，RRC接入请求次数变多还有伴随着大量失败，每天RRC成功率基本在20%左右，失败发生在忙时时段，影响全网KPI。问题分析：查看小区状态以及通道驻波均没有问题，从CDL中看：均是ENB下发RRC set up之后终端无响应造成RRC连接超时，导致RRC接入失败。查看基本上是UE ID为1和3的用户的失败，但是查看最近的RSRP均较高。定

21、位过程：查看小区的IOT以及小区状态正常，对此小区进行核查，发现参数在非持续调度功率设置上出现问题，当此小区是-95，全网当时都已经改成-70，通过对全网此参数的核查，发现还有NBYZ理工学院2FHTL-2也是设置为-95，指标也很差。解决建议：效果：把小区的非持续调度功率从-95修改到-70以后指标明显有提升：网元友好名时间RAB建立成功率分母单位:次RAB建立成功率分子单位:次RRC连接建立成功率分母单位:次RRC连接建立成功率分子单位:次RRC建立成功率NBYZ技侦大楼FHTL-02013/7/115151787798.72%NBYZ技侦大楼FHTL-02013/7/1235355453

22、98.15%NBYZ技侦大楼FHTL-02013/7/134440956063.16%NBYZ技侦大楼FHTL-02013/7/1420141273023.62%NBYZ技侦大楼FHTL-02013/7/1520141273023.62%NBYZ技侦大楼FHTL-02013/7/161351752514.29%NBYZ技侦大楼FHTL-02013/7/171271272318.11%NBYZ技侦大楼FHTL-02013/7/1834315316011.30%NBYZ技侦大楼FHTL-02013/7/1954501218771.90%NBYZ技侦大楼FHTL-02013/7/2019192625

23、96.15%NBYZ技侦大楼FHTL-02013/7/2113132020100.00%NBYZ技侦大楼FHTL-02013/7/2247475151100.00%NBYZ技侦大楼FHTL-02013/7/2322222828100.00%3.5.3 小区测试开关参数问题问题现象：在月苑二试扩L-3小区下收不到该小区信号，无法接入该小区，导致该路段信号较弱，较大区域形成弱覆盖。问题分析： 测试车辆在月苑南路自西向东行驶至和墨香路交叉口区域，在交叉口区域该站下无法收到该小区信号，导致该路段覆盖较差，严重影响下载速率，机房核查小区状态正常，无告警情况。图一在后台对比核查参数发现，小区加载开关打开，

24、且带真实用户的模拟快开关关闭，导致用户终端无法接入。MAC测试开关里有小区加载开关和带真实用户的模拟加载开关，小区加载开关打开的话，带真实用户的模拟加载开关就会生效。当需要加扰测试时需要把小区加载开关打开，而此时如果带真实用户的模拟加载开关关闭，表示小区处于模拟用户加载情况，真实用户不能接入，如果带真实用户的模拟加载开关打开，表示是用真实用户进行加载，则真实用户可以接入。月苑二试扩小区正是由于小区处于模拟加载状态，且关闭了带真实用户的模拟加载开关导致测试终端搜不到小区信号，无法正常接入；解决建议：关闭小区加载开关解决效果：关闭小区加载开关后，终端能正常搜到小区信号，且接入正常。如下图：问题总结

25、对于无法接入小区的问题，建议处理措施：a) 核查小区状态和告警以及硬件问题情况。b) 核查是否由参数问题导致小区加载开关默认关闭，在现网中进行模拟加载等测试时，测试完成后需要对参数及时进行恢复。3.5.4 内存池耗尽导致信令发送失败问题问题描述：南京F鼓楼四条巷专项L基站RRC接入失败率很高，查看指标时段趋势，在有业务的时段都有RRC接入失败率较高的问题存在。实时查看小区无上行干扰，由于RRC接入失败次数较多，影响全网全天的KPI指标数据。问题分析：从指标劣化趋势看，在7点左右统计的RRC接入失败次数最多，一个时段内高达22次的失败。从CDL信令看，UE在不断的在做TAU更新，RRC接入失败时

26、是由于在随机接入过程中，UE上发RRCConnectionRequest, ENB回复RRCConnectionSetup但可能UE未收到，导致RRC接入超时，ENB侧未收到RRCConnectionSetupComplete消息，具体CDL信令情况如下：通过NAS解码可以得出此为TAU过程：定位过程：从mapinfo中，目标基站F鼓楼四条巷专项L所处位置属于边缘覆盖，F鼓楼四条巷专项L-2和F鼓楼四条巷专项L-3小区覆盖方向无其他小区衔接覆盖。查看EXCEPTION日志，对应失败的时间点事 6:50 7:11 7:34 7:40，每个时间点都对应下面两条告警。未知的消息和定时器超时，从CDL

27、中统计失败原因都是收到RRC建立完成消息超时。通过分析日志，发现：半小时之间没有发送接收成功任何信令；存在很多信令发送失败的情况，原因为内存池耗尽。查看号日志以及控制台日志，和配置文件里，发现对端100.68.131.214和100.68.131.221同时配置为客户端和服务器，导致了基站SCTP内存池耗尽，消息发不出去，造成RRC接入失败。解决建议：1、 由于对端IP：100.68.131.214和IP:100.68.131.221同时配置为客户端和服务器，这个配置触发了内存耗尽，导致信令发送失败的现象，删除并只保留对端100.68.131.214和100.68.131.221配置为客户端和

28、服务器的其中一条。2、 升级新版本对此配置错误加保护，同时解决内存泄露的问题，以及增加对内存耗尽后的保护，来根本解决此问题的再次发生。3.5.5 全频带高干扰导致接入失败问题干扰定义：在每个子帧轮询一次后都会统计出在100个PRB中每个PRB的IOT值，当IOT值高于10的PRB个数大于等于3时为高IOT，查询18次（早9:00到晚18:00每个小时一次数据，统计上行两个时隙），如果同一个站点(包括3个小区)超过6次干扰判定为干扰小区，其中IOT超过20为干扰严重小区，IOT在1020之间的为干扰普通小区；如同一个小区多于6次超过80个PRB 的IOT大于15判定为全频带高干扰小区。问题描述：

29、宁波城市元年-2小区无线接通率只有59.38%，从信令流程上看到的是存在大量基站收不到终端发上来的RRCConnectionSetupComplete消息：问题分析：检查基站状态正常，查看小区无相关原因告警，从指标趋势看，平均分布在每个时段；从CDL信令看UE发起由于enb给UE发起RRCConnectionRequest后 ENB下发RRC connection setup 消息，但未收到终端上发的RRCConnectionSetupComplete消息，造成RRC连接建立完成超时，导致RRC连接建立失败。查询上行低噪，发现较多的PRB都存在较高的IOT值。对小区的IOT进行监控，可以看到高

30、干扰，并且邻区并无大量用户。解决效果：6月21日将城市元年-2小区PGC开关打开，该小区前后一周的KPI数据如下：ERAB掉线率无线接通率无线掉线率2013-6-140.56%59.38%5.26%2013-6-153.59%85.71%60.00%2013-6-160.00%82.14%0.00%2013-6-171.44%82.54%11.54%2013-6-180.68%89.31%3.57%2013-6-192.71%57.25%27.27%2013-6-200.00%100.00%0.00%14日-20日平均值1.28%79.48%15.38%2013-6-21（打开PGC开关）0.

31、33%97.44%0.00%2013-6-220.52%100.00%5.88%2013-6-230.00%98.39%0.00%2013-6-241.44%62.79%12.50%2013-6-251.18%92.86%6.82%2013-6-260.36%92.98%2.00%2013-6-270.73%96.00%2.38%2013-6-280.89%97.30%3.23%22日-28日平均值0.73%91.47%4.69%其中6月20日KPI数据异常，在未打开PGC开关的情况下各项KPI指标都非常好，查看KPI原始数据确认是当天业务量太少：RAB建立成功率分母单位:次RAB建立成功率分

32、子单位:次RRC连接建立成功率分母单位:次RRC连接建立成功率分子单位:次无线接通率1919643859.38%1010282485.71%1313282382.14%2726494282.54%5756888089.31%22221387957.25%4455100.00%6767787697.44%如上述表格数据说明，在打开PGC开关后，无线接通率有所提升。4 ERAB建立成功率4.1 理论介绍涉及话统打点图1 图2如或中A点所示，当eNodeB收到来自MME的INITIAL CONTEXT SETUP REQUEST或者E-RAB SETUP REQUEST消息时统计该指标。如果INIT

33、IAL CONTEXT SETUP REQUEST或者E-RAB SETUP REQUEST消息中要求同时建立多个E-RAB，则相应指标根据业务的QCI按具体的E-RAB建立数目分别进行累加。如或中B点所示，当eNodeB向MME发送E-RAB SETUP RESPONSE或者INITIAL CONTEXT SETUP RESPONSE消息时统计该指标。如果E-RAB SETUP RESPONSE或者INITIAL CONTEXT SETUP RESPONSE消息中同时携带多个E-RAB的建立，则相应指标按各个业务的QCI分别进行累加。指标指标描述小区E-RAB尝试建立总次数用户尝试发起E-R

34、AB建立流程的总次数小区E-RAB建立成功总次数用户发起E-RAB建立流程，建立成功的总次数小区E-RAB建立失败原因核心网问题导致E-RAB建立失败次数传输层问题导致E-RAB建立失败次数无线层问题导致E-RAB建立失败次数无线资源不足导致E-RAB建立失败次数安全模式配置失败导致ERAB建立失败次数此外，话统还针对各QCI进行了ERAB尝试建立次数和ERAB建立成功次数的统计。由于目前很少用到不同的QCI，业务基本以QCI6的业务为主，所以不需要关注具体的业务类别的ERAB统计。4.2 指标定义ERAB建立成功率小区E-RAB建立成功总次数/小区E-RAB尝试建立总次数100小区无线接通率

35、RRC建立成功率ERAB建立成功率。4.3 CDL信令流程及失败原因4.3.1 正常过程 上下文建立过程基本流程上下文建立过程基本流程上下文建立流程是以S1 Initial Context Setup Request开始，此后所有的消息都可以提取相同的eNBUEID。S1 Initial Context Setup Response消息标志着上下文建立基本流程的结束。S1 Initial Context Setup Request消息的详细解码结果中，E-RABToBeSetupListCtxtSUReq里面的承载个数等于1时，意味着这次上下文建立过程只是建立默认承载；而当此值大于1时，则意味

36、着这次上下文建立过程除了建立默认承载外还要建立专用承载。在S1 Initial Context Setup Response消息的详细解码结果中，E-RABSetupListCtxtSURes里面的承载个数代表建立成功的默认承载和专用承载数目，E-RABList里面的承载个数代表建立失败的默认承载和专用承载数目。 专用承载建立基本流程专用承载建立基本流程专用承载建立流程以S1 ERAB Setup Request消息开始，此后所有的消息都可以提取相同的eNBUEID。S1 ERAB Setup Response消息标志着专用承载建立基本流程的结束。4.3.2 异常过程i. 上下文建立过程中等待

37、UE能力信息超时上下文建立过程中等待UE能力信息超时当看到UE Capability Enquiry和S1 Initial Context Setup Failure消息并且第3条消息的value Cause字段的值为failure-in-radio-interface-procedure时，标志着上下文建立流程中UE能力信息超时。ii. 上下文建立过程中等待安全模式完成超时上下文建立过程中等待安全模式完成超时当看到Security Mode Command和S1 Initial Context Setup Failure消息并且最后一条消息的value Cause字段的值为failure-i

38、n-radio-interface-procedure时，标志着上下文建立流程中安全模式命令消息超时。iii. 上下文建立过程中等待RRC重配完成超时上下文建立过程中等待RRC重配完成超时当看到RRC Connection Reconfiguration和S1 Initial Context Setup Failure消息并且最后一条消息的value Cause字段的值为failure-in-radio-interface-procedure时，标志着上下文建立流程中空口重配置消息超时。iv. 上下文建立过程中AS安全失败上下文建立过程中AS安全失败当看到Security Mode Failu

39、re消息时，标志着上下文建立流程中安全配置失败。v. 上下文建立过程中传输错误上下文建立过程中传输错误当看到S1 Initial Context Setup Failure消息并且其详细解码中的value Cause字段为transport-resource-unavailable时，标志着上下文建立流程中传输错误。vi. 上下文建立过程中内部其他错误上下文建立过程中内部其他错误当看到S1 Initial Context Setup Failure消息并且其详细解码中的value Cause字段不为failure-in-radio-interface-procedure、transport-r

40、esource-unavailable和encryption-and-or-integrity-protection-algorithms-not-supported时，标志着上下文建立流程中内部其他错误。vii. 专用承载建立过程中等待RRC重配完成超时专用承载建立过程中等待RRC重配完成超时当看到RRC Connection Reconfiguration和S1 UE Context Release Request消息并且最后一条消息的value Cause字段的值为failure-in-radio-interface-procedure时，标志着专用承载建立流程中空口重配置消息超时。4.

41、4 相关案例介绍分析4.4.1 路由关系未配无法接入的问题问题描述：兰州LTE示范站，连接的是华为核心网，基站开通后，SCTP链路正常建立，小区正常，但是终端无法附着成功。问题分析：通过信令流程分析，在终端RRC建立完成，鉴权、安全流程完成后，核心网下发了终端上下文建立的请求 ，之后基站直接回复了上下文建立失败，失败原因value Cause : transport : transport-resource-unavailable，如下图：定位过程：根据信令流程提示，通过查看失败信令的前一条信令，核心网下发上下文建立请求消息中，携带的sgw iP地址如下图，转化成十进制是：100.89.1.1

42、：而在基站的传输配置中，检查路由配置关系中发现，基站路由中没有添加到100.89.1.1这个网段的路由，所以导致了终端由于没有传输路由而上下文建立失败。 解决效果：现场添加完成该网段路由后，终端附着成功，业务正常。4.4.2 网关IP配置错误导致无法附着问题描述：南京统计KPI指标发现南体分校试扩L ERAB建立全部失败，全天失败次数在两万多次，严重影响了全网指标。问题分析：通过提取该站的CDL log分析发现，终端RRC建立已完成，鉴权和安全也已通过，核心网下发了终端上下文建立的请求后，基站直接回复了上下文建立失败，失败原因value Cause : transport : transpor

43、t-resource-unavailable，通过ATP跟踪信令流程和CDL看到的结果一样，如下图：定位过程：从CDL log中的InitialContextSetupRequest消息中 transportLayerAddress B对应的是100.68.253.17，通过核查确认核心网侧的SGW IP确定是100.68.253.17。对enb侧的路由设置进行检查，S1链路断链恢复后，该基站的路由中包含100.68.253.17的路由。而后通过仔细核查该路由关系，发现该条路由关系中网关IP地址：100.68.132.129和基站的IP地址:100.68.129.145不在同一个网段内，检查原

44、始规划数据，发现和规划数据不一致，所以导致了终端由于传输错误而上下文建立失败。 解决效果：现场修改网关IP地址后，终端成功附着，业务正常。4.4.3 安全参数配置问题问题描述：福州移动使用三星S4终端无法附着，查看CDL，失败原因是“SecurityModeFailure”。问题分析：1、查看目前基站安全开关为关闭，当此开关关闭时，基站默认选择空算法EIA0进行完保。（协议规定安全开关关闭时，ENB默认一种算法进行完保，大唐目前默认空算法EIA0）查看安全开关节点：LMT-全局参数配置-全局测试开关-HL全局测试开关2、通过WIRESHARK抓包，终端上报的能力中，不支持空算法EIA0，所以终端接入时，基站使用默认空算法，导致终端安全模式失败。定位结果：打开安全开关，基站根据配置算法的优先级和终端支持的算法来选择对应适合的，即可保证终端完保通过。解决建议：按信令流程分析，当安全失败时，一般都是基站设置的算法终端部支持，所以首先查看安全开关是否关闭，如果关闭则打开。安全开关打开后，如果终端不支持第一优先级算法，则会根据算法优先级一一选择。解决效果：打开安全开关