4G优化案例：NB-IoT附着成功率低处理案例.docxVIP

NB-IoT附着成功率低处理案例 XX XX年XX月 目 录 TOC \o 1-2 \h \z \u 一、 问题描述 3 二、 分析过程 3 三、 解决措施 3 四、 经验总结 3  NB-IoT附着成功率低处理案例 XX 【摘要】8月6日省公司核心网反馈监控发现NB-IoT附着成功率较低，主要集中在XX市，经核心网统计，附着失败原因最多的是鉴权/安全模式消息无响应，导致消息反馈超时，释放UE上下文。为此无线侧联合水表厂家进行了详细的终端测试和信令分析。确定了问题原因，并通过修改无线参数解决该问题 【关键字】NB-IoT 附着成功率 【业务类别】优化方法 物联网 参数优化 问题描述 8月6日省公司核心网监控中心反馈NB-IoT附着成功率较低，主要集中在XX市。 分析过程 8月7日无线侧优化人员抵达富锦现场进行NB测试，测试40块水表，每个水表位置进行5~10次附着测试，共计完成近300次附着，未发生失败。 8月13日水表厂家携带5块水表终端抵达现场进行测试，本次测试为5块水表+1个NB测试模块共同附着，测试过程中发现附着失败概率很大。 通过前台的终端测试可以看出，单终端的附着成功率很高，多终端的附着成功较低，而整个富锦近5000块水表，且水表在凌晨2点~早上8点期间集中进行数据回传，两个相邻的水表数据回传间隔2秒。 通常一次附着流程大约在5~6秒左右，水表的上报机制意味着在这个时间段会有多个终端同时进行附着流程，容易出现附着失败的现象。结合核心网反馈的附着失败原因，我们接下来进行了信令分析，来判断鉴权/安全模式超时主要出现在哪个环节上。 前面提到了，核心网反馈的附着失败原因集中在鉴权/安全模式超时上，而我们要通过信令分析找到是在哪个环节上超时的，对于一次附着流程，从终端到核心网，时延长的可能有以下几种： 1、 核心网下达到信令到基站侧时间过长 2、 基站侧转发核心网信令至终端时间过长 3、 终端处理信令时间过长 4、 终端信令发送至基站侧时间长 以下为一次附着失败的信令，由基站侧和终端侧分别抓包的信令。 【终端侧信令】 【基站侧信令】 通过信令抓包可以看到，终端在14:36:50发起attach请求，基站在4秒后收到，这4秒是空口建立RRC连接的时间，属于正常现象。接下来attach消息直接透传至核心网，核心网在14:36:54收到attach请求后立即下发了鉴权请求，而终端在收到鉴权请求时已经是14:37:15，间隔了21秒，而在这21秒的时间内核心网因为第一次的鉴权没有得到响应（定时器为6秒），又继续下发第二次、第三次、第四次鉴权请求，直到第四次鉴权请求得到了响应（由于时延过大，实际响应的是第一次的鉴权请求），核心网又继续下发安全模式确认消息，而此时终端仍然需要处理之前的第二次、第三次、第四次的鉴权请求，因此不会处理安全模式确认消息，这时还未等终端处理完鉴权消息，核心网已经判定安全模式确认消息响应超时，释放了UE上下文，造成一次附着失败。 解决措施 通过信令分析可以基本确定，时延较大的环节是基站向终端转发鉴权消息，因此需要核查基站参数配置。 通过多天的参数对比核查，发现如下参数配置不合理。 覆盖等级 参数名称 参数含义 黑龙江原配置 黑龙江更改后配置 level 0 npdcchMaxNumRepRa RA的NPDCCH公共搜索空间的最大重复次数 16 4 level 1 npdcchMaxNumRepRa RA的NPDCCH公共搜索空间的最大重复次数 16 128 level 2 npdcchMaxNumRepRa RA的NPDCCH公共搜索空间的最大重复次数 16 1024 level 0 npdcchOffsetRa 用于NPDCCH公共搜索空间的偏移量 zero zero level 1 npdcchOffsetRa 用于NPDCCH公共搜索空间的偏移量 oneEighth zero level 2 npdcchOffsetRa 用于NPDCCH公共搜索空间的偏移量 zero zero level 0 npdcchStartSfRa 启动RA的NPDCCH公共搜索空间的子帧 v8 v16 level 1 npdcchStartSfRa 启动RA的NPDCCH公共搜索空间的子帧 v8 v16 level 2 npdcchStartSfRa 启动RA的NPDCCH公共搜索空间的子帧 v4 v16 level 0 iniNpdcchNumRepRa RA用NPDCCH的初始重复次数 r16 r4 level 1 iniNpdcchNumRepRa RA用NPDCCH的初始重复次数 r16 r128 level 2 iniNpdcchNumRepRa RA用NPDCCH的初始重复次数 r16