RadioLinkDeleteResponse 根据信令流程也就是说出现在RNC发出了RRC Connection Setup信令后，并且在规定的时间内没有收到UE的回应消息，才会出现这情况。
从整个信令的流程来看，RRC Connection Setup信令首先从RNC的控制面发出，经过内部处理，通过RNC与Node B之间的接口板，再经过传输线路到Node B与RNC的接口板，然后在Node B内部处理，再通过RRU经Uu口到UE。在这个环节中每一个环节出现问题都会出现没有响应的现象。从路测终端侧看，终端未收到RRC连接建立消息，由于终端在上报RRC链接请求后，收不到网络侧RRC链接建立，会重发RRC链接请求，据此可以判断网络侧下发的RRC链接建立消息终端未收到，需要在下行方向，排查问题，如Iub口传输丢包、FACH信道配置不正确。 3.2.2 常见原因
1）RNC硬件存在故障
RNC内部处理板或对外的接口板正在问题，不能正确地将RRC Connection Setup信令发送给Node B
2）传输存在问题
从RNC到Node B之间的传输存在问题，传输误码较大，丢包较多，造成不能正确地将RRC Connection Setup信令发送给Node B
3）Node B存在问题
Node B的某个板子存在问题，有可能不能正确地接收RNC传送来的信令，也能可能不能将信令在FACH完整地传送给RRU
4）RRU存在问题
RRU不能正确地接收UE上发的RRC Connection Setup Complete信令，或是不能正确地将RRC Connection Setup信令作传送给UE
5）参数设置存在问题
? SCCPCH的功率参数设置存在问题，导致UE无法正确接收RRU传来的信令
? 由于下行功率不足或存在下行干扰等原因，UE未收到RNC发送的RRC
CONNECTION SETUP消息；
? UE收到了RRC CONNECTION SETUP消息，也上发了RRC CONNECTION
SETUP COMPLETE消息，但由于上行功率不足或存在上行干扰等原因，RNC未收到该消息； 6）终端问题
UE收到了RRC CONNECTION SETUP消息，但由于消息错误或UE内部错误等原因，UE未发送RRC CONNECTION SETUP COMPLETE消息；
排查方法： 3.2.3 解决方法
查看RRC链接建立的上行时隙干扰情况，如果发现时隙干扰很大，查看NODEB载
扇是否正常，同时查看邻小区是否有大量同频邻区，若在话务量小的情况下，ISCP仍然很高，则干扰可能来自异系统，如：GSM，PHS等；
若网络侧没有收到RRC建立完成消息：则调整后台DPCH的期望接收功率，同时利用网规网优手段，降低上行方向上的干扰；
无效配置、配置不支持等配置错误：换个手机测试，若各厂家手机测试都有问题，将本小区RRC建立消息和正常小区的RRC建立消息进行对比，查看配置是否正确；
若UE未收到RRC建立消息：调整后台下行最小发送功率，增加UE接收到RRC建立消息的几率，或者调整周围网络的覆盖、频点、功率等，尽量降低下行方向上的干扰，或调整小区PCCPCH功率及公共信道、共享信道相关功率，确认Iub口传输无问题；
一般采用逐步判断的方法来定位问题，步骤如下： 1） 确定RNC已经收到了RRC Connection Request请求，并且已经发出了RRC
Connection Setup 信令
2） 确定RNC内部的各个处理板之间数据传输没有出现问题，可以使用系统工具
RDS进行各个处理板之间数据包的传输统计，评估其丢包率。
3） 查看传输告警，以及传输的内部告警，确保传输没有问题 4） 查看Node B的收包情况与RNC的送包数量一致，同时确定Node B在FACH上
正确完整地将数据传出。（使用工具LOGVIW和LMT）
5） 如果上以都不存在问题，重启RRU或更换RRU进行指标观察 6） 确定终端是否收到Node B传来的信令 7） 增加SCCPCH的功率，观察指标
4. 案例集锦
本文汇总了TD外场出现过的RRC建立成功率低的部分案例，并按照原因进行分类整理，以期对外场问题排查提供借鉴。
本文所选案例中，部分参考了各地用服网优整理的RRC建立成功率低问题处理总结。
4.1 CONGESTION原因：码资源不足
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC收到rrcConnectionRequest请求之后，直接下发了rrcConnectionReject消息。RRC建立KPI统计失败原因为CONGESTION.
RNC版本：V2.00.200e2，基站版本：V2.00.200fP003。
【排查方法】
（1） 在OMCR性能管理中，筛选CONGESTION高的小区； （2） 提取KPI综合分析（CS/PS流量），初步分析是否和码资源相关；如下表CONGESTION
次数高的时段，PS流量很大，很有可能是码资源不够。 按原因分NODEB 开始时间 时间粒度 RNC ID 服务小区 ID 小区类别 RRC连接请求次数 RRC连接失败计数器，分组域业务流量congestion (KByte) 19:00:00 1小时 20:00:00 1小时 21:00:00 1小时 22:00:00 1小时 23:00:00 1小时 1 1 1 1 1 9711 9711 9711 9711 9711 9713 室外小区 9713 室外小区 9713 室外小区 9713 室外小区 9713 室外小区 214 489 566 602 301 201 473 501 557 291 124865.2 194474.9 171392 168818.3 165699.8
（3） 通过LMT小区载波测量查看小区码资源配置及使用情况，并检查一下有没有载波（或
时隙）被闭塞现象（也可在OMCR NodeB动态数据管理中查看）。
【处理建议】
? 如有载波（或时隙）被闭塞，则解开。 ? 小区扩容 【典型案例】
东水西调3扇区.doc
4.2 NOREPLY原因：BBU TBPH FPGA异常
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC发出rrcConnectionSetup请求之后，但没有收到基站上报的RadioLinkRestoreIndication消息。RRC建立KPI统计失败原因为NOREPLY.
RNC版本：V2.00.200e2，基站版本：V2.00.200fP003。
【排查方法】
1、 在LMT上开启本地小区载波测量，看在小区空载情况下，同时存在以下情况
a) UPISCP值全为127
注：UpIscp值在50以下属于正常，前四个值不使用。 b) 上行时隙ISCP（底噪）值很大
注：空载时，Iscp值在-110左右属于正常 c) 上行时隙RTWP后四天线值很大
注：空载时，BBU RTWP值在-110左右属于正常）
2、 在OMCB上查询基站通知消息，可以看到TBPH单板有大量“上行IQ Link链路误码
(198081164)”通知上报。
3、 采集RRU命令日志， 看到testRTWP命令输出值正常
注：正常情况无UE接入时，RRU Shell显示的RTWP是底躁，应该在-69左右（此时DSP监控工具显示的底躁应该在-110dB左右），若低于-80dBm，则基本可认为RRU无上行信号；若大于-60dBm，则底躁过高，存在干扰。
【处理建议】 规避方法：复位小区所在TBPH单板。
具体原因仍在定位。
类似问题如果需要采集数据，请按以下文档采集:
RRC建立成功率低数据采集要求(0703更新
【典型案例】
石家庄市电炉厂.doc
4.3 NOREPLY原因：干放干扰
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC已经下发了rrcConnectionSetup请求，且能
收到基站上报的RadioLinkRestoreIndication消息,但收不到UE上报的rrcConnectionComplete消息。RRC建立KPI统计失败原因为NOREPLY.
RNC版本：V2.00.200e2，基站版本：V2.00.200fP003。
【排查方法】
2、 从LMT小区载波测量观察，UpIscp和上行时隙ISCP功率正常。
3、 测试终端为凯明，测试时发现在R01覆盖区域，各业务连接正常，但在干放覆盖区域，
手机一直无法接通。 【处理建议】
形成书面报告递交移动，推动干放厂家积极解决。 【典型案例】
崇文区新世界家园二期TDM.doc
4.4 NOREPLY原因：FACH出窗
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC已经下发了rrcConnectionSetup请求，但没有收到基站上报的RadioLinkRestoreIndication消息。RRC建立KPI统计失败原因为NOREPLY.
RNC版本：V2.00.200e2，基站版本：V2.00.200fP003。
【排查方法】
1、 打开LMT本地小区载波管理，如下图；
2、 选中RRC建立失败的小区载波，点击资源分配查询，查询载波所在基带板，如下图，载
波0在TBPE2上；
3、 在Logview中打开相应的基带板，待界面左上角的指示由红色变成蓝色之后，输入
TbpaInfoShow（注意大小写）命令，确认目标小区是否在该基带板上处理。如图：