TD上行同步与RRC建立请求关系
TD上行同步与RRC建立请求关系怎么样，如果未能与基站上行同步，UE会不会发送RRC建立请求给网络侧？RRC请求超时一般是什么原因？
TD要先进行上行同步才能进行RRC的连接建立。如果未能与基站同步，UE就不会发RRC Connect Request。但如果在鼎利软件测试的话UE不管怎么样都会发RRC，除非UE故障。
小区随即接入就需要上行同步了
在IDLE发起RRC连接首先需要上行同步
UE 和NODBE 建立下行同步，然后进行上行同步，通过FPACCH来调整手机的功率，手机上行同步后，发送RRC connection request 进行业务请求，T300超时，一般是因为无线环境太差导致NODBE 无法收到或UE 无法收到 RRC connection setup 造成T300超时。
不同步就没法"沟通"!
就好比不两个人之间交流一样!没有个顺序,你说我也顺不乱套了吗!
TD要先进行上行同步才能进行RRC的连接建立。如果未能与基站同步，UE就不会发RRC Connect Request
另外对于RRC连接建立问题的分析定位思路如下：
1) 如果发现UE侧显示多次发送RRC Connection Request而始终没有收到RRC Connection Setup消息，则最大的可能是物理层随机接入过程失败，可以通过调用Outum的FPACH信息和PRACH信息窗口进行确认；
a) 如果FPACH窗口显示没有收到Node B下发的FPACH，则说明的确没有收到Node B下发的FPACH。
根据SIB5，检查随机接入参数的配置，重点检查SYNC_UL的最大重发次数、基站期望的UpPCH接收功率、功率爬坡步长、同步尝试最大次数。尝试提升基站期望的UpPCH接收功率和功率爬坡步长，或者增大重发和尝试的次数，以增大Node B收到SYNC_UL的可能性。
检查UpPCH Shifting算法开关是否打开，打开算法开关，以免由于干扰造成Node B无法接收上行同步信号。对于干扰的分析可以结合ISCP的统计结果进行。
请机房核查FPACH的发射功率，尝试通过提高FPACH的发射功率解决随机接入问题；
还有一种可能就是网络侧配置的PRACH资源太少，由于资源冲突Node B不回FPACH，但这种情况会有一定概率收到FPACH的。
b) 如果FPACH窗口显示已经收到了FPACH，则需求根据网络侧的log分析RNC是否收到了RRC Connection Request消息
如果收到了RRC Connection Request，并发送了RRC Connection Setup，则需要分析为何UE没有收到RRC Connection Setup。此情况出现的概率非常小，出现该问题时建议检查基站侧告警，看是否存在FACH的出窗告警。
如果没有收到RRC Connection Request，则需要
检查Node B的状态，看是否存在故障告警；
检查PRACH配置的时隙位置，结合网络侧ISCP测量结果判断是否由于PRACH收到干扰而导致网络侧无法正确接收
2) 如果收到RRC Connection Reject，则需要根据其中携带的原因进一步分析。常见到的原因为资源拥塞。此时需要结合网络侧的log进一步定位问题。
a) 检查Iub接口无线链路建立是否成功，如果不成功则根据返回的原因值定位失败的具体原因。常见的失败返回值有硬件故障、协议错误、配置不支持等。
对于硬件故障，可以通过告警分析、基站状态查询等方式进行，同时还可通过网络侧的话务统计，看基站是否固定出现接入失败，多次失败是否存在相似性；
对于协议错误则需要仔细检查无线链路建立消息中是否包含非法参数；
对于配置不支持，一般会直接支出不支持的参数，通过将该参数修改为合理值即可解决；
b) 检查Iub接口ALCAP链路是否建立成功
需要根据ALCAP释放消息中携带的失败原因进一步定位失败的原因，常见的也是参数配置问题、硬件故障。
可以首先排除是否硬件故障，也是通过告警和基站状态查询的方式。
排除基站故障的原因后，仔细核查配置参数，可以重点关注两端参数的设置是否一致。
c) 检查是否由于RNC的RRM算法的本地资源分配失败导致。
资源分配是RRM算法的SDCA算法进行的，在大量用户情况下，一个小区的资源有限，无法满足某些用户资源请求，或其他原因导致本地分配失败或逻辑连接建立失败。而且资源不仅包含频率、时隙、码道，还包括功率等资源，任何一个不满足都会导致资源分配失败。
可以根据网络侧的信令跟踪确定是上行资源分配失败还是下行资源分配失败。并分析该小区的资源使用情况，确定是否真的没有资源，还是RRM算法参数设置或者由于RNC设备故障导致。分析过程还需要借助告警和网络侧的性能统计共同进行。
资源分配失败排除算法策略的因素或RNC故障外，需考虑是否是由于规划覆盖范围过大，或热点地区、临时聚集等因素考虑相应措施
3) UE侧收到RRC Connection Setup后没有发送RRC Connection Setup Complete而是又发送RRC Connection Request，则需要检查RRC Connection Setup消息中是否配置了UE不支持的配置。
4) UE侧收到RRC Connection Setup后没有发送RRC Connection Complete
a) 根据SIB1确定T312、N312的取值，请网络侧核查Node B侧配置的无线链路同步指示次数，确定是否由于这些定时器、计数器取值设置不合理导致同步失败；
b) 检查上行DPCH初始发射功率和下行DPCH的初始发射功率，排除由于功率设置不合适造成无法同步的问题；
c) 根据网络侧ISCP统计结果排除干扰问题导致的网络侧无法同步的问题；
5) UE发送了RRC Connection Setup Complete消息：
a) 检查上行DPCH初始发射功率，看是否由于功率配置的太小导致RNC没有收到；
b) 根据网络侧的ISCP统计结果看是否由于干扰导致网络侧没有收到！谢谢！
RRC请求超时，可能是无线环境的原因，可是如弱覆盖，或是接收信号的之恋较差。网络忙。
UE要想上发RRC连接请求，随机接入网络，就必须获得和网络的上行同步，读取帧消息，并计算路损、时间等，提前发送RRC请求，做到同一时隙的用户同一时间到达网络侧，
RRC连接超时，原因多种，可能网络信号不好，RRC请求，网络侧未收到，覆盖问题，可能上行干扰余量设置过小，RNC也接收不到，参数问题，可能定时器设置过小，帧碰撞，也是参数问题，要具体看信令来分析。