Attach接入故障排查思路

Attach过程成功率是衡量网络的一个很重要的接入指标，直接影响用户的体验，将接入成功率控制在一个合理的范围内，对用户体验相当重要。本文总结了常见接入过程中的故障，以供大家参考。...




c： 点击上方"mscbsc"↑订阅；成就卓越自我，打造通信第一在线学习平台

导读

Attach过程成功率是衡量网络的一个很重要的接入指标，直接影响用户的体验，将接入成功率控制在一个合理的范围内，对用户体验相当重要。本文总结了常见接入过程中的故障，以供大家参考。

随机接入过程

1基本原理

Attach过程的第一阶段是随机接入过程，随机接入过程又分为基于竞争的随机接入和基于非竞争的随机接入，具体流程分别如下图所示：图1 基于竞争的随机接入流程    图2 基于非竞争的随机接入流程

基于竞争的随机接入阶段包括从UE发送Msg1到UE收到Msg4竞争解决成功，本章先分析Msg1到Msg3可能出现的一些问题的排查思路，Msg4到Msg5在下一部分RRC连接建立阶段再做分析。

这个阶段出现的问题主要表现在：eNB收到的小区RRC建立请求数目比较少，Msg3检测成功次数很少，Msg3丢弃次数很多。在Msg3失败的情况下，信令跟踪上不会有任何消息，这类问题主要靠抓取UE侧log进行分析。

2排查思路

问题定位思路如下图所示：

1.   UE发送Msg1后接收Msg2失败

随机接入失败最常见的表现是UE发送Msg1，但是接收Msg2失败，具体分析有三种情况：

1） UE没有收到RA-RNTI加扰的PDSCH

• 这种情况一般是基站没有检测到UE发送的Msg1，需要查看UE侧的RSRP是否过低，UE处于超远点，要重新选点接入；
• 另外，需要查看SIB2消息中的prach配置的preambleInitialReceivedTargetPower是否设置过低，可以尝试提高Msg1的初始发送功率。
• 如果都不行，则可能是基站软件出现问题，基站收到Msg1后调度Msg2失败，需要抓取Cmac打印信息。

2） UE收到Msg2中的PreambleID与发送的不匹配

若从UE log找到RA-RNTI加扰的PDSCH信息，并且CRC结果是OK的，则查看高通log中的0xB063  LTE MAC DL Transport Block，找到Msg2发送的时刻，查看Rapid Val值（如下图所示）是否与UE发送的Msg1中PreambleID一致，不一致则可认定是基站检测Msg1出现了异常，一般是由于RRU光纤时延出现问题。

3） UE检测Msg2的PDSCH CRC Fail

查看UE侧log，查看0xB173  LTE PDSCH Stat Indication中RA-RNTI加扰的PDSCH的CRC Result：如果是Fail，则表示是由于UE收到的Msg2的PDSCH CRC错，一般是终端侧异常引起的。

2.      UE发送的Msg3 Harqfail

如果在UE log中查看Msg4 fail了，则有可能是因为Msg3 Harqfail，基站不发送Msg4，UE侧竞争解决定时器超时。

此时再查看UE的Msg3 Report，确定发送时刻后，查看PHICH上的反馈是否为NAK。如果PHICH上显示Msg3每一次传输之后UE收到的都是NAK，则说明Msg3 Harqfail了。

RRC连接建立过程

1基本原理

eNB侧控制面收到RrcconnectionRequest消息之后，开始RRC连接建立过程，如下A点，控制面发出RrcConnectionSetup消息之后，启动2s的定时器，等待接收RrcConnectionSetupComplete消息，在定时器超时之前收到RrcConnectionSetupComplete则RRC连接建立成功，如下图B点。

对于RRC连接建立失败，可以先通过KPI查询失败原因，然后针对每一种原因再进一步分析。

2排查思路

RRC连接建立失败，主要有三类原因：Msg5定时器超时、eNB接纳失败、其它原因，常见的排查思路如下图所示：

1.   定时器超时

目前商用网络中最常见的失败类型就是Msg5定时器超时，T300定时器超时。

2.    Msg4空口发送过晚

如果判定为Msg4失败，则进一步可能是在eNB发送空口Msg4过晚，超过了UE侧的竞争解决定时器，或者Msg4底层出现了harqfail，先说Msg4发送过晚的问题，又可细分为集中情况：

1） Rnlu投递Msg3到Rnlc过晚，导致相应的空口Msg4过晚；

2） Rnlc收到Msg3后，发送Msg4过晚：

这个也可以从信令跟踪确认，直接看RrcConnectionRequest与RrcConnectionSetup消息的时间差，正常情况下是几ms，如果过大，则Rnlc处理有问题。例如下面的这种情况相差60ms左右，必然会导致Msg4竞争解决失败。

3） Cmac调度Msg4过晚：

这种情况最可能的是下行调度器收到Msg4的BSR后，UE实例没有建立完成，一直等待超过64ms。其它原因如RB分配失败、CCE分配失败也会反映到这个统计上，如果要细化原因，需要打印内部log。

3.      Msg4 harqfail

这种情况在实验室环境还大量存在，最早抓取过UE侧log，最主要的现象是UE会突发性的在几十秒的时间内下行PDSCH全错，如下图所示，包括广播、Msg2、Msg4，Msg2偶尔能对。

这种情况现在没有什么办法，只能是通过不统计重传的RrcConnectionRequest解决。

注：协议里UE发送RRC层的RRCConnectionRequest消息之后，启动T300定时器，并触发MAC层的随机接入，T300定时器超时后UE侧才认为本次RRC连接建立失败，触发新的RRC连接建立请求。在T300定时器运行期间UE经过多少次MAC层的随机接入才收到RRCConnectionSetup消息，UE侧RRC层是不关注的，只有MAC层的随机接入失败达到eNB配置的最大传输次数，才会通知到RRC层。

4.  Msg5空口传输失败

Msg5失败的可能原因有：

1） 没有收到Ue发送的调度请求（Pucch或Prach）

对于配置了SR资源的UE，UE会发送SR请求上行资源，对于没有配置SR资源的UE，UE通过Prach请求调度。

ü  ULPhy没有收到UE在PUCCH信道上发送的SR的情况，周懿在测试部环境发现过一次，当时的现象：小区先接入1000UE，再接入200UE时，Msg5大量的超时，跟踪信令查看Msg3投递以及Msg4调度都没有问题。CMAC调度Msg4之后，没有重传，UE应该是一次就成功收到了Msg4。查看上行调度，第一次收到UE发送的SR已经超过了2s，进一步分析发现PHY主控每TTI处理的PUCCH UE数有限制，最大为64，当小区建立的RRC连接用户数达到一定数量后，每TTI需要发送PUCCH的UE数超过了64，导致UE发送的SR不被接收。

ü  UE发送的Prach不被基站响应

主要是CPU过载控制策略存在问题。

典型案例：某外场压力测试RRC连接建立成功率低

比如之前的策略：Cmac统计每秒Msg3 CRC OK的次数达到门限之后，不处理后续的Msg1，不区分Msg3的类型。当系统中存在大量建立了RRC连接但是没有配置SR资源的UE时，这些UE只要有上行业务就要通过一次接入将BSR发送给eNB，这种类型的接入不占CC资源，每秒几十到上百次，Cmac统计的Msg3 CRC OK个数很容易就达到70的门限。当有UE初始接入的时候，就会出现下面的情况：

UE收到RRCConnectionSetup消息，没有配置SR资源，UE发送Msg5时先要通过一次接入将Msg5的BSR带给eNB，但是Cmac统计到的Msg3 CRC OK次数达到了门限，不响应Msg1，UE没办法将Msg5的BSR发送给eNB，Msg5发送失败。因此，问题的原因是Cmac统计的Msg3 CRC OK的次数太容易达到70的门限了，当配置多个小区时，门限更低。

2） 收到调度请求后度不及时

调度Dci0之后，空口质量太差，PUSCH传输失败。E-RAB建立阶段

1基本原理

eNB收到MME发送的Initial context setup request消息后开始统计初始E-RAB建立指标，如下图A点，eNB收到UE发送的RRCConnectionReConfigurationComplete消息后，给MME发送Initial context setup response，则统计初始E-RAB建立成功，如下图B点。

2排查思路

1.   空口失败

如果从KPI Counter获取到E-RAB建立失败的原因为空口失败，则可信令跟踪进一步确认是哪条消息空口失败了。

抓取Cmac一级打印log，分析空口传输是否有异常，上行大量harqfail或是下行大量harqfail，或是上下行无调度。如空口传输无异常，则可能是eNB发送的消息有异常，需要分析信令字段填写是否有误。

例如之前出现过：

1） 用户面将MAC-I字段填错，导致UE收到能力级查询消息后，不发送能力级信息；

2） 控制面在Msg4消息中新增了一个信元后某些CA终端不发送RRC重配完成消息。

对于下行传输正常，上行传输失败的场景，分析方法类似Msg5，根据路损和NI信息分析理论Sinr是否低于对应调度MCS的解调门限。

另外，还有一些排查思路：

1） DRX功能问题

在RRCConnectionReconfiguration消息中，一般会给UE使能DRX，如果DRX功能出现问题，可能会出现基站侧与UE状态不一致造成上下行大量DTX的现象。

2） 上行PUSCH功控问题

例如某外场出现过，在NI较大的情况下，上行功控配置为P0 = -75，RRCConnectionReconfiguration配置为绝对式功控。而Msg3固定TPC = 8dB，Msg4配置为累积式功控。这种配置下就会出现RRCConnectionReconfiguration之后，UE清空f(i)，上行发射功率骤降，RRCConnectionReconfigurationComplete发送失败。修改为累积式功控方式后解决这种现像。

2.   其它原因

其它原因的失败，外场最常见的有两种情况：

1） MME定时器超时

爱立信核心网在给eNB发送Initial context setup request消息后，会启动一个2s的定时器，定时器超时还未收到eNB发送的Initial context setup response消息，则爱立信核心网会直接给eNB发送Initial context Release Command，这种情况eNB会统计E-RAB建立失败，原因值为other。

2） UE在其它小区接入

UE如果在E-RAB还未建立完成时，又到其它小区接入成功，则MME会给第一次接入的eNB发送Initial context Release Command，这种情况eNB会统计E-RAB建立失败，原因值为other，这种情况与UE的行为相关，eNB侧只能先排除空口传输时延大的问题。

    关注 mscbsc