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

1、 LTE R3.0 专项问题定位总结报告专项问题定位总结报告 之“接入成功率较低” LTE R3.0 技术文档技术文档 V1.0 2011 年年 10 月月 11 日日 修订历史记录 日期日期版本版本作者作者备注备注 编制 姓名姓名签字签字日期日期电话电话 薛旭2011-10-11 审查 姓名姓名签字签字日期日期电话电话 审核 姓名姓名签字签字日期日期电话电话 批准 姓名姓名签字签字日期日期电话电话 文档评审负责人： 参加评审人员： 目录 1引言引言.4 1.1编写目的.4 1.2预期读者.4 1.3参考资料.4 2问题描述问题描述.4 2.1问题背景.4 2.2问题现象.7 3问题定位过程问

2、题定位过程.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 1引言 1.1编写目的 本文档对 LTE R3.0 项目测试过程中“终端接入成功率较低”问题的解决过程进行了 详细的描述，并针对各种可能的场景给出了基本的定位方法，为后续测试过程中终端接 入失败问题的定位提供参考。 1.2预期读者 本文档的读者是 LTE R3.0 项目软件开发人员、软件测试人员、测试线支持人员以

3、及相关的系统测试人员。 1.3参考资料 1.TD-LTE eNodeB R3.0 系统流程设计说明书.doc 2.TD-LTE eNodeB 高层软件架构设计说明书-控制面.doc 3.基带专项问题定位总结报告-消息 3 译码错误率高.doc 2问题描述 2.1问题背景 本专项测试的目的是解决终端初始接入时的各种问题，提高 UE 接入成功率，因此 本文提供的分析以接入场景为基础。Error! Reference source not found.描述了初始附着 流程的关键步骤：当终端在目标小区成功驻留后，就可以发起随机接入请求，即发送 Msg1(Random Access Preamble)，

4、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)；而后，终端完成上行发射时间调整和功控， 并

5、根据小区系统信息和调度授权信息在 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 Conne

6、ction Setup)。UP MAC 分配 Msg4 资源后，指示给 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

7、鉴权和加密过程。 之后，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 完成 Att

8、ach 流程。 注：1. 图 2-1 中将 NAS 消息的传递过程简化，实际需要 MAC 不断的进行资源调度。 2. 图中将 CP 对 L2 的配置和重配流程简化，实际需要 CP 对 L2 的各层 （MAC、RLC、PDCP）依次进行操作。 图 UEBBUPCP Synchronization Signals UP_BB_PHY_PBCH_REQ MIB UP_BB_PHY_PDCCH_REQ UP_BB_PHY_PDSCH_REQ SIB1 SIB2SIB5 Msg1: Random Access Preamble BB_UP_PHY_PRACH_IND UP_BB_PHY_PDCCH_RE

9、Q 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

10、_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: Au

11、thentication 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_RECONF

12、IG_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 de

13、fault bearer NAS: Attach Accept NAS: Attach Request 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 连接

14、重建请求， 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 若再次接 入会被拒

15、绝，若再次重建则会重建拒绝。 4)由于 eNB 与 MME 之间的 S1 链路出现闪断，导致 MME 收不到 eNB 发送的 S1AP 消息； 基于以上 4 种可能的原因，针对目前出现的不同现象来分别分析，确定了每种现象 的定位思路： 现象现象 1 测试时，抓取 BB 对于 Msg1Msg5 的统计 Log，和 UP MAC 的 Log，并结合 OMCR-CT 捕包工具。如果捕包工具上没有任何码流，再查看 BB 和 MAC 的 Log。若发 现 BB 收到多次 Msg1，但是收不到消息 2，并且 MAC Log 中存在处理消息 1 时分配 Temp UE ID 失败指示，则可以确定是由于原因

16、1 导致接入失败。 现象现象 2 当服务小区质量低于规定门限时，UE 会重新进行小区搜索，并接收系统信息，若 系统信息中的 TAI 不在核心网下发的 TAI List 中时，UE 会主动上报 TAU 请求。如果 UE 不断地上报 TAU，说明 eNB 侧配置的 PLMN ID 与核心网下发的不一致，此时需要 检查 eNB 侧的 PLMN 配置。 现象现象 3 eNB 执行 RRC 连接重建流程，若将 UE 释放，说明 eNB 侧的处理中出现错误导致。 抓取 OMCR-CT 码流，检查重建流程哪里出现错误。 （本次测试出现的是 PDCP 重激活 失败） 现象现象 4 eNB 侧 CP 处理 RR

17、C 连接重建时，没有将原有的 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 发送 初始上下文，并

18、且反复以上流程，但从 MME 侧的码流没有发现 eNB 侧发送的此消息。 则可以确定是 eNB 和 MME 之间的链路存在问题。 3.2定位过程 此次专项测试中出现的问题集中在 UP MAC 的接入过程，和 CP 对 RRC 连接重建 处理流程。现象 6 出现一次之后没有再次复现，因此重点分析现象 15 的定位过程。 现象现象 1 使用创意视讯的 P3A 数据终端进行测试，反复附着去附着后，发现接入失败。查看 UE 侧 Log 显示，接收 Msg2（RAR）超时，并且反复出现。 抓取 UP MAC 的 69 号窗口的 Log，李昂发现临时 UE ID 耗尽，查看 Msg3 和 Msg4 的计数

19、器计数，发现不一致。查看 CCCH（消息 4）相关计数器，发现消息 4 比消息 3 计 数器正好少 50 个（临时 UE ID 的总数） ，怀疑 CCCH 消息没有及时发送给 MAC。由于 MAC 维护临时 UE ID 是基于 CCCH 消息的 HARQ 反馈的，CCCH 消息的缺失就会导致 1629EL1C: MSG1 target preample rx pow is 54 1629EL1C: prach_cfg_id is 5 1629EL1C: power ramp is4 1629EL1C: rach ctrl at 537, sf is 7 1629EL1C: ra_rnti: 3

20、 1629EL1C: n_ra_prb: 6 1629EL1C: preample_format: 0 1629EL1C: RA response timer is 21 1632EL1C: RAR expire at sfn=539, sf=8 临时 UE ID 的挂死，李昂加入竞争决议定时器机制，用来维护临时 UE ID 和消息 4 的重 调度。但加入此机制后问题 1 依旧复现，查看 UP Trace 发现在随机接入过程中经常出现 解复用模块的告警，经闫英杰和李昂确认，此时解复用模块与随机接入模块之间接口 UE ID 参数传递错误，导致在收到包含 CRNTI MAC CE 的消息 3 后（

21、如果消息 3 中不包含 CCCH 消息或信令消息，CP 不会发送消息 4，能够解释为何 CCCH 消息比 MSG3 少）无 法释放临时临时 UE ID 导致资源耗尽。修改后能够正常释放临时 UE ID。李昂和闫英杰 分析，此时消息 3 为“上行数据到达”场景下的消息 3。为何初始随机接入过程中会走 到“上行数据到达”？李昂初步怀疑 UE 有消息 5 之后的消息需要上报，而此时 UE 的 TA 定时器已经超时，经过安思麒，李昂，和闫英杰确认，此时消息 3 中包含需要传递给 RLC 层的数据包，拆包后发现此包为 UE 上报的状态 PDU（NACK） ，MAC 解复用模块 修改传递级别，使在线非激活

22、用户的状态 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 0

23、1，而核心网在 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 的问题定位结束。

24、现象现象 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 在处理重建消息

25、时，需要更新 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 | 置为空

26、。但从 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- RN

27、TI 没有找到对应的 UE 上下文，从而发送 RRC 重建拒绝。经过分析，此问题的出现 是由于在第一次重建时，没有将新的 C-RNTI 与对应的 UE 上下文关联导致。修改 CP 代码后问题解决。 至此，现象 5 的问题定位完毕。 4问题分析与总结 本专项测试过程中，发生接入失败的问题主要集中在 UP MAC 的随机接入过程和 CP RRC 层 RRC 连接重建的处理流程： 当出现接入失败问题时，首先查看 OMCR-CT 码流，分析信令流程： 1)如果没有收到 Msg3，则需要分析 UP MAC 和 BB 的 Log。BB 的分析可以参考附 件基带专项问题定位总结报告-消息 3 译码错误率高.

28、doc文档中的说明进行定 位；UP MAC 的 Log 通过在 CPB 板 69 号窗口抓取，按照现象 1 的定位过程进行 定位。 2)如果收到 Msg3，并且附着成功后发起了 RRC 连接重建，并反复出现 TAU 过程。 则需要查看 LMT-B 中“小区 RRM 参数 1PLMN 配置”中的 MNC 和 MCC 配置是 否正确。应该按下图配置： 3)如果 RRC 连接重建失败，并 CP 发起了 UE 释放，则需要确认重建流程走到哪一 步了，根据实际情况定位。若 PDCP 重激活响应消息中 Result 为 1，则表示返回失 败响应，此时原因大致可以确定为 PDCP 维护的 SRB 或 DRB

29、 状态不正确导致， 需要 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

30、确认是否将 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 节。 5.2.2UE 插拔后，第二次发起附着 数据卡终端附着成功后，直接拔掉，此时 eNB 和 MME 都不知道该 UE 已经不在线了， 仍然都保存着该 UE 的上下文。当 UE