请看信令里的cause是啥？

RRC 建立失败就会走重建流程

RRC重建很多，都是被拒绝有可能是站点未开放和,导致终端无法附着!

失步、完整性校验失败、达到最大重传次数等都会导致无线资源的重建。重建要成功，首先要确定重选的小区是否存有已经挂起的无线承载资源信息。

一直感觉网优的东西会受很多方面的影响

重建的原因在重建请求消息中、一般都是other failure/handover failure。

提供个思路：
1，rrc reestablishment request携带的short MAC-I 是否正确？
2，如果是切换失败导致的重建，且重建场景发生在target cell，则重建是否会被eNB接受需要看target cell中是否有该UE的上下文（即如果是inter-ENB切换，是否有X2口用来传递UE的上下文），如果target cell没有该UE context，重建会被eNB拒绝，然后UE需要再发起TAU Request流程。

补上以上第2条的协议依据：
参考36331

A UE in RRC_CONNECTED, for which security has been activated, may initiate the procedure in order to continue the RRC connection. [color=Yellow]The connection re-establishment succeeds only if the concerned cell is prepared i.e. has a valid UE context.[/color]

1、重复重建也会被拒绝；
2、short MAC-I较验失败也会被拒绝

如果一直重建失败，是否不插板终端将无法恢复数据业务？还是一次重建失败就发起TAU?

第一次重建失败或者被拒，就直接发起TAU

提供个思路：
1，rrc reestablishment request携带的short MAC-I 是否正确？


怎么确定short MAC-I正确，和小区参数对比吗？具体如何确定？

[b]建议先确定以下几点：
是否是切换过程的重建？如果是：[/b]
1，RRC重建请求消息是在原小区发送的还是目标小区发送的？
2，如果是原小区上发送的重建请求，可以排查下short mac-i，这个需要PDCP的人去看看，具体的算法过程和计算模型，请参考33401 7.4.3和36331 5.3.7.4
（In order to calculate the token, the source eNB shall use the negotiated EIA-algorithm from the AS Security context from the source eNB with the following inputs: source C-RNTI, source PCI and target Cell-ID as defined by VarShortMAC-Input in TS 36.331 [21], where source PCI and source C-RNTI are associated with the cell the UE last had an active RRC connection with and target cell ID is the identity of the target cell where the RRCConnectionReestablishmentRequest is sent to.
- KEY shall be set to KRRCint of the source cell;
- all BEARER bits shall be set to 1;
- DIRECTION bit shall be set to 1;
- all COUNT bits shall be set to 1.
The token shall be the 16 least significant bits of the output of the used integrity algorithm.
）
3,如果是目标小区上发送的重建,看看测量报告有没有发送成功，如果没发送成功，目标小区就拿不到UE context当然就无法计算出mac-I，那么重建被拒就是正常

嗯，所以你现在的思路是？

好高深

重建失败（包括收到重建被拒），就会发起TAU