LTE30专项问题定位总结报告-接入成功率较低.doc

LTE R3 0 专项问题定位总结报告专项问题定位总结报告 之 接入成功率较低 LTE R3 0 技术文档技术文档 V1 0 2011 年年 10 月月 11 日日 修订历史记录 日期日期版本版本作者作者备注备注 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 1 1 页页 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 2 2 页页 编制 姓名姓名签字签字日期日期电话电话 薛旭2011 10 11 审查 姓名姓名签字签字日期日期电话电话 审核 姓名姓名签字签字日期日期电话电话 批准 姓名姓名签字签字日期日期电话电话 文档评审负责人 参加评审人员 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 3 3 页页 目录 1引言引言 4 1 1编写目的 4 1 2预期读者 4 1 3参考资料 4 2问题描述问题描述 4 2 1问题背景 4 2 2问题现象 7 3问题定位过程问题定位过程 7 3 1定位思路 7 3 2定位过程 8 4问题分析与总结问题分析与总结 10 5附录附录 12 5 1文档附件 12 5 2OMCR CT 码流 12 5 2 1第一次初始附着码流 12 5 2 2UE插拔后 第二次发起附着 13 5 2 3RRC连接重建流程 14 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 4 4 页页 1引言 1 1编写目的 本文档对 LTE R3 0 项目测试过程中 终端接入成功率较低 问题的解决过程进行了 详细的描述 并针对各种可能的场景给出了基本的定位方法 为后续测试过程中终端接 入失败问题的定位提供参考 1 2预期读者 本文档的读者是 LTE R3 0 项目软件开发人员 软件测试人员 测试线支持人员以 及相关的系统测试人员 1 3参考资料 1 TD LTE eNodeB R3 0 系统流程设计说明书 doc 2 TD LTE eNodeB 高层软件架构设计说明书 控制面 doc 3 基带专项问题定位总结报告 消息 3 译码错误率高 doc 2问题描述 2 1问题背景 本专项测试的目的是解决终端初始接入时的各种问题 提高 UE 接入成功率 因此 本文提供的分析以接入场景为基础 图 2 1 描述了初始附着流程的关键步骤 当终端在 目标小区成功驻留后 就可以发起随机接入请求 即发送 Msg1 Random Access Preamble eNodeB 的 BB 检测并处理完 PRACH 后会将每个用户的前导码序列指示 PreambleIndex 定时提前量 TA 用户标识 RA RNTI Prach 接收功率 PrachPower 几个关键参数传到 UP MAC 然后由 UP MAC 调度 DL SCH 物理层链路依次为 PDCCH 和 PDSCH 将随机接入响应消息 Msg2 Random Access Response 反馈给终端 消 息中至少包括检测出的 PreambleIndex TA 用于指示 Msg3 资源的调度授权信息和分 配临时用户标识 TC RNTI 而后 终端完成上行发射时间调整和功控 并根据小区系 统信息和调度授权信息在 UL SCH 物理层链路为 PUSCH 上发送无线链路连接请求 即 Msg3 RRC Connection Request 对 eNodeB 侧来说 UP MAC 会在下发 Msg2 后通过上行接收请求帧指示 BB 接收 PUSCH 其中请求帧的配置参数要与发给终端的 Msg2 中调度授权信息一致 当 BB 根 据指示接收并处理完 PUSCH 后 将译码后数据和 CRC 校验结果反馈到 UP MAC 并由 UP MAC 解复用之后给 CP RRC 层 CP 根据实际情况指示 UP 和 BB 建立用户 待建立 用户成功之后下发 Msg4 RRC Connection Setup UP MAC 分配 Msg4 资源后 指示给 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 5 5 页页 BB 通过空口下发给 UE UE 收到 Msg4 后 为了发送 Msg5 RRC Connection Setup Complete 而上报 SR 请求上行资源 eNB 侧 MAC 完成上行资源调度后 通过 DCI0 指示给 UE 然后 UE 将 Msg5 协同 Attach Request NAS 消息一起上发到 eNB CP eNB CP 收到 Msg5 后 向 MME 发起初始 UE 流程 其中携带 Attach Request 消息 MME 收到 UE 的附着请求后 两者之间通过上下行直传消息完成 NAS 鉴权和加密过程 之后 MME 向 CP 发送初始上下文建立请求 同时携带了 Attach Accept 消息 按照 MME 指示 CP 需要获取 UE 能力传递给 MME 然后 CP 进行网络侧和 UE 之间的加密 过程 MME 与 UE eNB 与 UE 之间的通道都完成加密过程后 CP 通过 RRC 连接重配进 行 SRB2 和默认 DRB 的建立 并通过 RRC 连接重配消息将 Attach Accept 消息带给 UE UE 完成建立 SRB2 和 DRB 流程后 给 eNB 侧发送 RRC 连接重配完成响应 并通 过 Attach Complete 消息指示 MME 完成 Attach 流程 注 1 图 2 1 中将 NAS 消息的传递过程简化 实际需要 MAC 不断的进行资源调度 2 图中将 CP 对 L2 的配置和重配流程简化 实际需要 CP 对 L2 的各层 MAC RLC PDCP 依次进行操作 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 6 6 页页 图 UEBBUPCP Synchronization Signals UP BB PHY PBCH REQ MIB UP BB PHY PDCCH REQ UP BB PHY PDSCH REQ SIB1 SIB2 SIB5 Msg1 Random Access Preamble BB UP PHY PRACH IND UP BB PHY PDCCH REQ UP BB PHY PDSCH REQ Msg2 Random Access Response Msg3 Scheduled Transmission RRC Connection Request BB UP PUSCH IND UP RRM MAC DATA IND RCP BB PHY CONFIG REQ BB RCP PHY CONFIG CNF RCP L2 RRC CONNECTION CONFIG REQ L2 RCP RRC CONNECTION CONFIG CNF RCP UP MAC DATA REQ RRC Connection Setup UP BB PHY PDCCH REQ UP BB PHY PDSCH REQ Setup SRB1 Msg4 Contention Resolution RRC Connection Setup Scheduling Request BB UP PUCCH IND UP BB PHY PDCCH REQ MME DCI0 Msg5 RRC Connection Setup Complete BB UP PUSCH IND UP RCP PDCP DATA IND InitialUEMessage NAS Attach Request NAS Authentication Request NAS Authentication Response NAS Security Mode Command NAS Security Mode Complete InitialContextSetupRequest UECapabilityEnquiry UECapabilityInformation SecurityModeCommand SecurityModeComplete RCP BB PHY RECONFIG REQ BB RCP PHY RECONFIG CNF RCP L2 RRC CONNECTION RECONFIG REQ L2 RCP RRC CONNECTION RECONFIG CNF RCP UP PDCP DATA REQ RRC Connection Reconfig NAS Attach Accept UP BB PHY PDCCH REQ UP BB PHY PDSCH REQ RRCConnectionReconfiguration NAS Attach Accept RRCConnectionReconfigurationComplete NAS Attach Complete InitialContextSetupResponse NAS Attach Complete Setup SRB2 and DRB for non GBR default bearer NAS Attach Accept NAS Attach Request LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 7 7 页页 2 1 UE 初始附着信令流程 2 2问题现象 在专项问题定位测试线 反复进行终端附着去附着操作 以及插拔操作 出现多次 附着失败 可以分为 6 种 1 多次附着去附着后 UE 无法收到消息 2 RAR 捕包工具 OMCR CT 抓不到 任何消息 2 终端发起 RRC 连接重建后 不断发送位置区更新请求 3 UE 发起 RRC 连接重建 流程完成后 CP 将其释放 4 出现现象 4 后 UE 再次发起附着 CP 会拒绝 5 RRC 连接重建成功后 UE 或再次发起 RRC 连接重建请求 eNB 侧 CP 发送 拒绝消息 6 eNB 侧多次向 MME 发送初始上下文消息 但 MME 未收到 3问题定位过程 3 1定位思路 根据 UE 附着接入流程以及本次专项测试的问题定位经验 UE 附着失败的问题主 要可以归结为以下几种原因 1 UE 反复附着去附着后 UP MAC 在处理消息 1 时 分配 Temp UE ID 失败 导致 Msg2 下发失败 2 由于 eNB 发送的系统信息中的 PLMN ID 与核心网的 PLMN 不一致 导致 UE 不断发起 TAU 3 CP 处理 RRC 连接重建时 对 UE 上下文的处理存在问题 导致 UE 若再次接 入会被拒绝 若再次重建则会重建拒绝 4 由于 eNB 与 MME 之间的 S1 链路出现闪断 导致 MME 收不到 eNB 发送的 S1AP 消息 基于以上 4 种可能的原因 针对目前出现的不同现象来分别分析 确定了每种现象 的定位思路 现象现象 1 测试时 抓取 BB 对于 Msg1 Msg5 的统计 Log 和 UP MAC 的 Log 并结合 OMCR CT 捕包工具 如果捕包工具上没有任何码流 再查看 BB 和 MAC 的 Log 若发 现 BB 收到多次 Msg1 但是收不到消息 2 并且 MAC Log 中存在处理消息 1 时分配 Temp UE ID 失败指示 则可以确定是由于原因 1 导致接入失败 现象现象 2 当服务小区质量低于规定门限时 UE 会重新进行小区搜索 并接收系统信息 若 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 8 8 页页 系统信息中的 TAI 不在核心网下发的 TAI List 中时 UE 会主动上报 TAU 请求 如果 UE 不断地上报 TAU 说明 eNB 侧配置的 PLMN ID 与核心网下发的不一致 此时需要 检查 eNB 侧的 PLMN 配置 现象现象 3 eNB 执行 RRC 连接重建流程 若将 UE 释放 说明 eNB 侧的处理中出现错误导致 抓取 OMCR CT 码流 检查重建流程哪里出现错误 本次测试出现的是 PDCP 重激活 失败 现象现象 4 eNB 侧 CP 处理 RRC 连接重建时 没有将原有的 C RNTI 对应的标志位清空 但 MAC 释放掉原 C RNTI 后 UE 再次附着时会将该 C RNTI 再分配 因此 CP RRC 判断 RRC 连接建立请求消息中的 C RNTI 时 发现对应资源已经占用 从而发送拒绝消息 现象现象 5 eNB 侧 CP 处理 RRC 连接重建时 没有将新的 C RNTI 与对应的 UE 资源相关联 因此 CP 根据 RRC 连接重建消息中的 C RNTI 查找 UE 失败 从而发送重建拒绝消息 现象现象 6 从 OMCR CT 捕包工具发现 UE 不断地发起附着 信令流程到 eNB 给 MME 发送 初始上下文 并且反复以上流程 但从 MME 侧的码流没有发现 eNB 侧发送的此消息 则可以确定是 eNB 和 MME 之间的链路存在问题 3 2定位过程 此次专项测试中出现的问题集中在 UP MAC 的接入过程 和 CP 对 RRC 连接重建 处理流程 现象 6 出现一次之后没有再次复现 因此重点分析现象 1 5 的定位过程 现象现象 1 使用创意视讯的 P3A 数据终端进行测试 反复附着去附着后 发现接入失败 查看 UE 侧 Log 显示 接收 Msg2 RAR 超时 并且反复出现 抓取 UP MAC 的 69 号窗口的 Log 李昂发现临时 UE ID 耗尽 查看 Msg3 和 Msg4 的计数器计数 发现不一致 查看 CCCH 消息 4 相关计数器 发现消息 4 比消息 3 计 数器正好少 50 个 临时 UE ID 的总数 怀疑 CCCH 消息没有及时发送给 MAC 由于 MAC 维护临时 UE ID 是基于 CCCH 消息的 HARQ 反馈的 CCCH 消息的缺失就会导致 1629 EL1C MSG1 target preample rx pow is 54 1629 EL1C prach cfg id is 5 1629 EL1C power ramp is4 1629 EL1C rach ctrl at 537 sf is 7 1629 EL1C ra rnti 3 1629 EL1C n ra prb 6 1629 EL1C preample format 0 1629 EL1C RA response timer is 21 1632 EL1C RAR expire at sfn 539 sf 8 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 9 9 页页 临时 UE ID 的挂死 李昂加入竞争决议定时器机制 用来维护临时 UE ID 和消息 4 的重 调度 但加入此机制后问题 1 依旧复现 查看 UP Trace 发现在随机接入过程中经常出现 解复用模块的告警 经闫英杰和李昂确认 此时解复用模块与随机接入模块之间接口 UE ID 参数传递错误 导致在收到包含 CRNTI MAC CE 的消息 3 后 如果消息 3 中不包含 CCCH 消息或信令消息 CP 不会发送消息 4 能够解释为何 CCCH 消息比 MSG3 少 无 法释放临时临时 UE ID 导致资源耗尽 修改后能够正常释放临时 UE ID 李昂和闫英杰 分析 此时消息 3 为 上行数据到达 场景下的消息 3 为何初始随机接入过程中会走 到 上行数据到达 李昂初步怀疑 UE 有消息 5 之后的消息需要上报 而此时 UE 的 TA 定时器已经超时 经过安思麒 李昂 和闫英杰确认 此时消息 3 中包含需要传递给 RLC 层的数据包 拆包后发现此包为 UE 上报的状态 PDU NACK MAC 解复用模块 修改传递级别 使在线非激活用户的状态 PDU 也能传递给 RLC 层 至于 UE TA 模块为 何会超时 需要进一步加以分析 测试过程中发现消息 3 的误码率偏高 李昂和务志坤修改消息 3 分配资源的方式和 RU 个数 使消息 3 对应的短截调制编码方式可配 最小为 3 同时支持最大给 MSG3 分配 2 个 RU 经过验证 为提高 MSG3 的解码成功率有一定帮助 至此 现象 1 的问 题定位完毕 现象现象 2 从 OMCR CT 上查看码流 可以看到 UE 不断地发起 TAU 流程 分析 TAU Request 携带的 Last visited registered TAI 得到 PLMN ID 为 001 01 而核心网在 Attach Accept 中携带的 PLMN ID 为 460 00 查看 LMT B 中配置的 MNC 和 MCC 全为 1 此配置错 误导致 UE 在服务小区服务质量太差 重新搜索小区接收 SIB1 消息时 会得到错误的 PLMN ID 因此会发起 TAU 将 eNB 配置参数 MNC 修改为 460 MCC 修改为 1 后问 题解决 反复发起 TAU 时 查看小区信号质量很差 从而触发 UE 的重新搜索小区流程 王亮从 RRU 输出的功率看出现 10db 的跳变 将 RRU 的功率检测关掉后 没有再次出 现此现象 问题 2 解决 至此 现象 2 的问题定位结束 现象现象 3 分析 OMCR CT 的码流 发现在完成 RRC 重建流程之后 对 eNB CP 对 PDCP 重激 活流程中 PDCP 返回失败 从而导致 CP 发起 UE 释放 PDCP 同事查看代码 发现 按照当前的重建流程 在重激活时 SRB2 的状态不正确导致 PDCP 返回激活失败 该 问题是由前期切换测试修改代码引入 现已修改 现象现象 4 抓取 MCB 板 10 号窗口的 Log 发现当 UE 再次接入时 携带的 C RNTI MAC 分 配 相关的 UE 上下文不为空 从而导致 CP 将其拒绝 此 C RNTI 时 RRC 连接重建使 用的 C RNTI CP 在处理重建消息时 需要更新 C RNTI 将原 C RNTI 对应的标志位 ER SFN 0687 SubSFN 0 CCIdx 0 CUIdx 0012 MacRandomAccess 2116 RarInDemux None ClearCrnti None TempUeid 12 NULL None ER SFN 0687 SubSFN 0 CCIdx 0 CUIdx 0012 MacRandomAccess 2122 RarInDemux None ClearUeCtx None TempUeid 12 NULL None LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 1010 页页 置为空 但从 Log 分析 确定是在重建时没有正确处理 C RNTI 更新过程 分析 CP RRC 连接重建流程 发现在更新 C RNTI 时 没有将原 C RNTI 对应的标 志位置为 0 重建失败会给 UP MAC 发送释放 UE 请求 MAC 将原 C RNTI 回收再利 用 因此 UE 再次接入时 使用回收的 C RNTI 由于 CP 此时该 C RNTI 标志位为 1 从而接入失败 CP 修改 RRC 连接重建流程代码后 问题解决 至此 现象 4 的问题定位结束 现象现象 5 分析 MCB 板 10 号窗口的 Log UE 第二次发起 RRC 连接重建请求时 CP 通过 C RNTI 没有找到对应的 UE 上下文 从而发送 RRC 重建拒绝 经过分析 此问题的出现 是由于在第一次重建时 没有将新的 C RNTI 与对应的 UE 上下文关联导致 修改 CP 代码后问题解决 至此 现象 5 的问题定位完毕 4问题分析与总结 本专项测试过程中 发生接入失败的问题主要集中在 UP MAC 的随机接入过程和 CP RRC 层 RRC 连接重建的处理流程 当出现接入失败问题时 首先查看 OMCR CT 码流 分析信令流程 1 如果没有收到 Msg3 则需要分析 UP MAC 和 BB 的 Log BB 的分析可以参考附 件 基带专项问题定位总结报告 消息 3 译码错误率高 doc 文档中的说明进行定 位 UP MAC 的 Log 通过在 CPB 板 69 号窗口抓取 按照现象 1 的定位过程进行 定位 2 如果收到 Msg3 并且附着成功后发起了 RRC 连接重建 并反复出现 TAU 过程 则需要查看 LMT B 中 小区 RRM 参数 1 PLMN 配置 中的 MNC 和 MCC 配置是 否正确 应该按下图配置 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 1111 页页 3 如果 RRC 连接重建失败 并 CP 发起了 UE 释放 则需要确认重建流程走到哪一 步了 根据实际情况定位 若 PDCP 重激活响应消息中 Result 为 1 则表示返回失 败响应 此时原因大致可以确定为 PDCP 维护的 SRB 或 DRB 状态不正确导致 需要 PDCP 同事结合状态机转换机制分析重建流程是否正确 4 如果 RRC 连接重建失败 eNB 和 MME 释放 UE 后 UE 再次发起附着失败 则需 要查看 MCB 板 10 号窗口的 Log 查找显示为 Error 的 Trace 若存在 GRMCOMM AllocUeId GRM UE CTXT exists by C RNTI 则需要 CP 同事 确认当前 MCB 版本是否解决了 RRC 连接重建处理有误的问题 5 如果信令流程中发现已经发送了 Msg4 但 CP 因没有收到 UE 发送的 Msg5 而等 待超时将 UE 释放 此时需要 UP 确认是否将 Msg4 调度给 UE 并确认 UE 是否收 到 Msg4 以及是否发送了 Msg5 该问题出现不多 后续测试中没有复现 6 如果 UE 反复附着 一般是因为小区信号质量不稳 导致 UE 掉话重新进行小区搜 索并附着 并反复进行该过程 本专项测试发现的问题已经定位并解决 并且接入成功率达到 95 以上 但还存在一 些在本次测试没有出现的场景和问题 有待解决和定位 一旦出现 按照本文总结的经验 和定位方法 也是不难定位的 5附录 5 1文档附件 1 基带专项问题定位总结报告 消息 3 译码错误率高 基带专项问题定位 总结报告 消息3译码错误率高 doc 5 2OMCR CT 码流 OMCR CT 码流显示了 CP 高层的板间消息交互过程 5 2 1第一次初始附着码流 关于附着流程的描述请参见 2 1 节 LTE R3 0 专项问题 定位总结报告之 接入成功率较低 第第 1212 页页 5 2 2UE 插拔后 第二次发起附着 数据卡终端附着成功后 直接拔掉 此时 eNB 和 MME 都不知道该 UE 已经不在线了 仍然都保存着该 UE 的上下文 当 UE 再次发起附着时 由于 MAC 又重新为其分配了新的 C RNTI 并且 CP 只是根据 C RNTI 来判断 UE 是否已经存在 而不