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

LTE R3.0专项问题定位总结报告

之“接入成功率较低”

LTE R3.0技术文档

V1.0

2011年10月11日

修订历史记录

日期

版本 作者

备注

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

第 1 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

编制

姓名 签字 日期 电话 薛旭

2011-10-11 审查

姓名 签字 日期 电话 审核

姓名 签字 日期 电话

批准

姓名 签字 日期 电话

文档评审负责人：

参加评审人员：

第 2 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

目录

1

引言 ............................................................................................................................................ 4 1.1 1.2 1.3 2

编写目的 ............................................................................................................................ 4 预期读者 ............................................................................................................................ 4 参考资料 ............................................................................................................................ 4

问题描述 .................................................................................................................................... 4 2.1 2.2

问题背景 ............................................................................................................................ 4 问题现象 ............................................................................................................................ 7

3 问题定位过程 ............................................................................................................................ 7 3.1 3.2

定位思路 ............................................................................................................................ 7 定位过程 ............................................................................................................................ 8

4 5

问题分析与总结 ...................................................................................................................... 10 附录 .......................................................................................................................................... 11 5.1 文档附件 .......................................................................................................................... 11 5.2 OMCR-CT码流 ............................................................................................................... 11 5.2.1 第一次初始附着码流 ............................................................................................... 11 5.2.2 UE插拔后，第二次发起附着................................................................................. 12 5.2.3 RRC连接重建流程 .................................................................................................. 13

第 3 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

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资源后，指示给

第 4 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

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）依次进行操作。

第 5 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

UEBBUPCPMMESynchronization SignalsUP_BB_PHY_PBCH_REQMIBUP_BB_PHY_PDCCH_REQUP_BB_PHY_PDSCH_REQSIB1SIB2~SIB5Msg1: Random Access PreambleBB_UP_PHY_PRACH_INDUP_BB_PHY_PDCCH_REQUP_BB_PHY_PDSCH_REQMsg2: Random Access ResponseMsg3: Scheduled TransmissionRRC Connection RequestBB_UP_PUSCH_INDUP_RRM_MAC_DATA_INDRCP_BB_PHY_CONFIG_REQBB_RCP_PHY_CONFIG_CNFRCP_L2_RRC_CONNECTION_CONFIG_REQSetup SRB1L2_RCP_RRC_CONNECTION_CONFIG_CNFRCP_UP_MAC_DATA_REQ(RRC Connection Setup)UP_BB_PHY_PDCCH_REQUP_BB_PHY_PDSCH_REQMsg4: Contention ResolutionRRC Connection SetupScheduling RequestBB_UP_PUCCH_INDUP_BB_PHY_PDCCH_REQDCI0Msg5: RRC Connection Setup CompleteNAS: Attach RequestBB_UP_PUSCH_INDUP_RCP_PDCP__DATA_INDInitialUEMessageNAS: Attach RequestNAS: Authentication RequestNAS: Authentication ResponseNAS: Security Mode CommandNAS: Security Mode CompleteUECapabilityEnquiryUECapabilityInformationSecurityModeCommandSecurityModeCompleteRCP_BB_PHY_RECONFIG_REQBB_RCP_PHY_RECONFIG_CNFInitialContextSetupRequestNAS: Attach AcceptRCP_L2_RRC_CONNECTION_RECONFIG_REQL2_RCP_RRC_CONNECTION_RECONFIG_CNFRCP_UP_PDCP_DATA_REQ(RRC Connection Reconfig)NAS: Attach AcceptUP_BB_PHY_PDCCH_REQUP_BB_PHY_PDSCH_REQRRCConnectionReconfigurationNAS: Attach AcceptSetup SRB2 and DRB for non-GBR default bearerRRCConnectionReconfigurationCompleteNAS: Attach CompleteInitialContextSetupResponseNAS: Attach Complete图

第 6 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

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会重新进行小区搜索，并接收系统信息，若系

第 7 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

统信息中的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）超时，并且反复出现。

[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: preample_format: 0 [1629]EL1C: n_ra_prb: 6 [1629]EL1C: RA response timer is 21 [1632]EL1C: RAR expire at sfn=539, sf=8 抓取UP MAC的69号窗口的Log，李昂发现临时UE ID耗尽，查看Msg3和Msg4的计数器计数，发现不一致。查看CCCH（消息4）相关计数器，发现消息4比消息3计数器正好少50个（临时UE ID的总数），怀疑CCCH消息没有及时发送给MAC。由于MAC维护临时UE ID是基于CCCH消息的HARQ反馈的，CCCH消息的缺失就会导致临

第 8 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

时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模块为何会超时，需要进一步加以分析。

[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 | 测试过程中发现消息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对应的标志位置为空。但从Log分析，确定是在重建时没有正确处理C-RNTI更新过程。

第 9 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

分析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配置是否正确。应该按下图配置：

3) 如果RRC连接重建失败，并CP发起了UE释放，则需要确认重建流程走到哪一步

第 10 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

了，根据实际情况定位。若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译码错

5.2 OMCR-CT码流

OMCR-CT码流显示了CP高层的板间消息交互过程。

5.2.1 第一次初始附着码流

关于附着流程的描述请参见2.1节。

第 11 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低” 消息3 消息4 消息5

5.2.2 UE插拔后，第二次发起附着

数据卡终端附着成功后，直接拔掉，此时eNB和MME都不知道该UE已经不在线了，仍然都保存着该UE的上下文。当UE再次发起附着时，由于MAC又重新为其分配了新的C-RNTI，并且CP只是根据C-RNTI来判断UE是否已经存在，而不对IMSI进行检查，所以eNB是无法得知该UE的原上下文仍然存在；MME收到对UE Attach Request时，发现相同IMSI的UE上下文已经存在，所以首先通知eNB将原有的UE释放，再继续进行UE新的附着流程。

第 12 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

核心网发现同一IMSI的UE上下文已存在，从而首先发起释放命令，通知eNB将原有的UE释放。之后继续新UE的接入流程。

5.2.3 RRC连接重建流程

RRC连接重建流程详细内容请参见参考资料1和2中相关描述。

第 13 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

本次测试中，CP在处理UE发起的RRC连接重建流程，重激活PDCP时，PDCP返回错误指示，从而导致发起UE释放流程。由于CP重建流程处理异常，导致UE再次附着时，CP发送RRC连接拒绝消息。此处由于CP发送此消息时SAP点填写错误，所以此消息在码流中未能显示，同时MAC也无法处理该消息。该问题在主分支代码中已经解决。 1. RCP只是发起了eNB侧的UE释放，并没有通知MME释放UE

如下码流显示，在PDCP重激活失败后，CP只是完成了eNB侧UE的释放过程，并没有通过MME释放对应的UE上下文，由此就会导致eNB和MME维护的UE上下文不一致。为了避免异常流程，建议修改PDCP重激活失败处理流程，通知MME同时释放UE。

重激活SRB1、SRB2和DRBs PDCP返回重激活错误指示，导致UE释放。但没有通知MME。RCP对L1L2也发送了释放消息，码流未显示。

此消息是RRC连接拒绝消息，SAP点应为RRM_MAC_DATA_REQ 2. 修改RCP处理PDCP重激活失败响应处理流程，通知MME释放UE 当PDCP返回重激活失败后，CP会在将eNB侧的UE释放同时，也通知MME将该UE释放，从而保证了eNB和MME之间UE上下文的一致性。

第 14 页

LTE R3.0专项问题

定位总结报告之“接入成功率较低”

重建SRB1。 重建SRB2，重配SRB2和DRBs。 通知MME发起UE释放。

第 15 页