流程交互失败导致RRC失败(一)
eSRVCC切换过程与RRC重建立过程并发导致eSRVCC切换失败案例
eSRVCC切换过程与RRC重建立过程并发导致eSRVCC切换失败案例
【问题描述】
Co352_1在发生eSRVCC的切换过程中，突发出现RRC重建立请求，随后基站向MME上发
HandoverCancel消息导致一次eSRVCC切换失败，基站向MME上发HandoverCancel信令截图如下：
【问题分析】
从信令来看，基站向UE发送Mobility From EUTRA Command后，核心网应该向基站侧下发Ue Context Release Command的消息，但基站一直没收到这样的消息，导致后面基站向MME回复Handover Cancel消息(Cause: interaction-with-other-procedure，)出现切换失败。基站没收到核心网下发的Ue Context Release Command消息的主要原因为基站在那时也收到了由UE上发的RRC重建立请求消息，由于RRC重建立消息与eSRVCC切换消息并发导致了此次切换失败，Handover Cancel解析出的原因为interaction-with-other-procedure，表示有其它程序干扰导致切换失败。且从ENB收到MME下发的Handover Command消息到ENB上发给MMEHandover Cancel消息之间的时间差为164ms, 现网参数TS1RLOCoveral S1切换保护定时器设置为10000ms，并没有超时。正常的eSRVCC切换信令截图如下：
基站向MME上发HandoverCancel信令失败原因截图如下：
【问题解决】
该问题是过程冲突问题，需基站侧改进判决机制解决（例如在TS1RLOCoveral超时前遇到RRC重建立时，ENB可不直接向核心网发送Handover Cancel消息，在TS1RLOCoveral范围内若RRC
重建立成
功可继续进行eSRVCC信令流程）。另外，可对一些特殊场景进行eSRVCC门限优化，避免在eSRVCC切换过程中由于RSRP骤降导致eSRVCC切换失败。
流程交互失败导致RRC失败(二)
切换失败原因分析
切换失败原因分析
1、 软切换失败原因
根据信令流程，导致切换失败的情形有以下几种
1）、ASU消息过多问题
切换参数不合理的导致乒乓切换
例如切换参数reporting range 1A和reporting range 1B的差别很小，那么小区刚进入AS又马上移出AS；如果Hysteresis 1C设置太小，那么一个刚被替换进AS的小区又马上移出AS。
导频污染
UE不断上报测量消息，RNC不断下发ASU消息，容易导致切换失败。
2）、软切换优化注意问题
控制软切换比例
网络建设初期，容量不受限制，以提升覆盖为目标。软切换比例可容许在40%甚至更高。这样可以保证上行良好覆盖并且可以减少掉话，由于软切换带来分集增益，从而降低了UE发射功率。当网络不断发展，由于容量问题凸现，由于软切换带来上下行系统硬件开销以及消耗下行码资源。综合考虑容量和覆盖问题，将软切换控制在一个合理的比例，通常为30-40%。
保证软切换成功率和低掉话绝对值
以合理的网络规划和合理的软切换参数为前提，保证切换的及时性。
减少乒乓切换
减少乒乓切换，以减少信令交互和资源消耗，从而降低掉话率。乒乓切换调整有几个方面，控制导频污染，通过切换参数克服。例如调整1A和1B的迟滞，增大Time to trigger参数。根据不同的场景设置不同的小区参数。
2、 ISHO失败原因
上行链路质量差【流程交互失败导致RRC失败】
事件2D门限（CM START）设置不合理
时间3A参数（ISHO）设置不合理
当前W小区漏配GSM邻区
当前W小区配置GSM邻区过多
目标GSM小区无可用无线资源
当前ISHO优化主要针对W覆盖边界与GSM覆盖区的优化。若W边界GSM小区覆盖较好，则有利于向GSM切换。若GSM信号强度不够，则增大了异系统测量失败或者信令交互失败的可能，从而导致掉话。所以W覆盖内部应尽量达到信号的连续覆盖，减少弱覆盖和盲区。使得ISHO发生在W覆盖区域的边缘，减少ISHO的次数。另外W系统间切换应尽量选择在人口密度小的区域，减少切换次数，也避免了因处理能力不足而使信令交互延时或失败，最终导致掉话。
3、3G-2G切换的触发条件:
1、如果是CPICH Ec/No触发了压缩模式，那么满足
GSM小区RSSI > gsmThresh3a 并且
CPICH Ec/No < usedFreqThresh2dEcno+utranRelThresh3aEcno - hysteresis3a/2门限的条件，并保持TimeToTrigger3a，将触发3G/2G切换。【流程交互失败导致RRC失败】
2、如果是CPICH RSCP触发了压缩模式，那么满足
GSM 小区RSSI > gsmThresh3a 并且
CPICH RSCP < usedFreqThresh2dRscp+utranRelThresh3aRscp - hysteresis3a/2 门限的条件，并保持TimeToTrigger3a，将触发2G/3G切换。
3、如果是Ue Tx power触发了压缩模式，那么满足
GSM小区 RSSI > gsmThresh3a 并且
CPICH RSCP < usedFreqThresh2dRscp+utranRelThresh3aRscp+utranRelThreshRscp
附：切换信令流程
软切换信令流程步骤：
1. SRNC决定建立一条新的无线链路，该无线链路所属的新的小区由另一个RNC（DRNC）控制。SRNC通过RNSAP向DRNC发送“Radio Link Setup Request”消息，请求DRNC准备相应的无线资源。由于新的无线链路是UE同DRNC建立的第一条无线链路，于是建立新的Iur信令连接。该Iur信令连接承载跟UE相关的RNSAP信令。
Radio Link Setup Request”消息包含的参数为：小区ID、TFS、TFCS、频率、上行扰码。
2. DRNC根据无线资源判定是否可以满足请求的无线资源要求，如果可以满足，DRNC向属于它的Bode B发送NBAP消息——无线链路建立请求“Radio Link Setup Request”。然后Node B启动上行接收。
“Radio Link Setup Request”消息包含的参数为：小区ID、TFS、TFCS、频率、上行扰码。
3. Node B按照要求分配无线资源，如果配置成功，Node B通过NBAP消息——无线链路建立响应“Radio Link Setup Response”向DRNC上报。
“Radio Link Setup Response”消息包含的参数为：信令终止，传输层寻址信息（AAL2寻址、用于数据传输承载的AAL2捆绑ID）
4. DRNC通过RNSAP发送无线链路建立响应消息“Radio Link Setup Response”给SRNC。
“Radio Link Setup Response”消息包含的参数为：传输层寻址信息（AAL2寻址、用于数据传输承载的AAL2捆绑ID），邻近小区信息。
5. SRNC通过ALCAP协议启动Iur/Iub数据传输承载，该请求包含AAL2捆绑ID用于绑定Iub数据传输承载和DCH。
6./7. Node B 和 SRNC通过交换相应的DCH FP帧“Downlink Synchronisation”和“Uplink Synchronisation”建立数据传输承载的同步。 Node B启动下行发送。
8. SRNC通过DCCH向UE发送激活集更新消息“Active Set Update”，该消息包含无线链路增加和删除内容。
参数：更新类型、小区ID、下行扰码、功率控制信息、邻近小区信息
9. UE根据RRC信令配置相应参数后，去活要删除链路的下行接收，激活要增加链路的下行接收，并向SRNC发送RRC消息“Active Set Update Complete”。
10. SRNC向Node B发送NBAP消息消息无线链路删除请求“Radio Link Deletion Request”。Node B停止接收和发送。
参数：小区ID、传输层寻址信息
11. Node B去活无线资源，并向SRNC发送NBAP消息无线链路删除响应“Radio Link Deletion Response”。
12. SRNC通过ALCAP协议启动释放Iur/Iub数据承载。【流程交互失败导致RRC失败】
硬切换信令流程步骤：
1. SRNC向目标RNC发送无线链路建立请求消息“Radio Link Setup Request”。
参数：目标RNC标识符、s-RNTI、小区ID、TFS、TFCS。
2.目标RNC为RRC连接和无线链路分配RNTI和无线资源，并发送NBAP消息“无线链路建立请求（Radio Link Setup Request）”给目标Node B。
参数：小区ID、TFS、TFCS、频率、上行扰码、功率控制信息等。
3.目标Node B分配无线链路资源，启动物理层接收，并发送NBAP消息“无线链路建立响应（Radio Link Setup Response）”给目标RNC。
参数：信令终止、用于Iub数据传输承载的传输层寻址信息。
4.目标RNC用ALCAP协议启动Iub数据传输承载的建立。该请求包含AAL2捆绑ID用于绑定Iub数据传输承载和传输信道DCH，同时该请求由Node B确认。
5.当目标RNC完成准备过程，目标RNC发送“无线链路建立响应”给SRNC。
6. SRNC:用ALCAP协议启动Iur数据传输承载的建立。该请求包含AAL2捆绑ID用于绑定Iur数据传输承载和传输信道DCH，同时该请求由目标RNC确认。
7. SRNC向UE发送RRC消息“物理信道重配置（Physical Channel Reconfiguration）”。
8. 当UE从旧的链路切换到新的链路时，源Node B检测到旧链路同步失败，发送NBAP消息“无线链路失败指示（Radio Link Failure Indication）”给源RNC。
9. 源RNC发RNSAP消息“无线链路失败指示（Radio Link Failure Indication）”给SRNC。
10.当与目标RNC的RRC连接建立并分配相应的无线资源后，UE发送RRC消息“物理信道重配置完成（Physical Channel Reconfiguration Complete）”给SRNC。
11. SRNC给源RNC发送RNSAP信令“无线链路删除请求（Radio Link Deletion Request）”给源RNC，要求源RNC释放相应的旧链路所用资源。
12. 源RNC给源Node B发送NBAP消息“无线链路删除请求”。
13. 源Node B释放旧链路无线资源，并向源RNC发送NBAP信令“无线链路删除响应（Radio Link Deletion Response）”。
14. 源RNC用ALCAP协议启动释放Iur数据传输承载。
15. 当源RNC完成释放Iur数据传输承载，发送RNSAP消息“无线链路删除响应”给SRNC。用ALCAP协议启动Iur数据传输承载的释放。该请求包含AAL2捆绑ID用于绑定Iur数据传输承载和传输信道DCH，同时该释放请求由目标RNC确认。
系统间的切换信令流程步骤：
1.SRNC发送RANAP消息“重定位请求（Relocation Required）”给CN。
2.UMTS CN通过MAP/E接口将重定位请求转发给GSM MSC。
3.正常GSM信令处理过程，MSC通过BSSMAP给BSC发送消息“切换请求（Handover Request）”。
4.正常GSM信令处理过程，BSC通过BSSMAP给MSC发送消息“切换请求响应（Handover Request Ack）”。
5.GSM MSC/BSS完成初始过程，MSC发送MAP/E消息“准备切换响应（Prepare Handover Response）”给CN。
6.CN发送RANPA消息“重定位命令（Relocation Command）”给SRNC。
7.通过已有的RRC连接，SRNC发送RRC消息“HANDOVER FROM UTRAN COMMAND”给UE，实现系统间硬切换。
8.正常GSM信令处理过程，BSC通过BSSMAP给MSC发送消息“切换检测（Handover Detect）”。
9.正常GSM信令处理过程，UE给BSC发送“切换完成(Handover Complete)” 消息。
10.正常GSM信令处理过程，BSC通过BSSMAP给MSC发送消息“切换完成（Handover Complete）”。
11.GSM检测到UE，MSC发送MAP/E消息“发送终止信号请求（Send End Signal Request）”给CN。
12.CN启动释放SRNC为旧链路分配的资源，通过发送RANAP消息“Iu释放命令消息（Iu Release Command）”。
13.SRNC释放承载资源，发送Iu释放完成消息“Iu Release Complete”给CN。
14.CN发送MAP/E消息“发送终止信号响应（Send End Signal Response）”给MSC。
流程交互失败导致RRC失败(三)
LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功
关键字：X2IPPATH 切换
【现象描述】
切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，
HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】
对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：
（1）传输资源不够用；
（2）没有配置IPPATH；
（3）IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】
每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。从该次切换的切换命令
（RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。在webLMT上的命令如下：
LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId，查看X2口两端的IP配置是否正确。
经过以上步骤的核查，发现目标基站B2虽然配置了与源基站B1间的X2接口（从DSP
X2INTERFACE命令的显示结果可以看到已配置），但是没有配置相应的IPPATH（通过LST IPPATH命令看不到X2口对应的IPPATH）。导致站点B1向B2发送X2口切换请求（HANDOVER_REQUEST）后，收到基站B2发回的X2切换准备失败消息（HANDOVER_PREPARATION_FAILURE），导致切换不成功。
用ADD IPPATH命令配置了站点B2到站点B1的IPPATH后（源站点也要有X2口的配置以及从B1到B2的IPPATH），可以进行正常的X2口站间切换。
【告警信息】无
【建议总结】
在网络负荷不大的情况下，X2口切换准备失败的原因通常与IPPATH配置有关，所以在配置
IPPATH时一定要仔细认真，源站与目标站双向配置，预防漏配错配的问题，提高切换成功率。
切换过晚导致切换失败
关键字：切换 小区偏置 信道质量陡降
【现象描述】
在切换流程进行中，目标小区信号质量出现抖动，信道质量陡降导致切换失败。在L3信令的表现为：源小区eNB收到多条测量报告，并且下发切换命令。
而UE未收到切换命令，并且仍然周期上发测量报告，直到发起重建，切换失败。
【原因分析】
1、从最后一个测量报告内容看，服务小区无线质量比邻区差6dB，根据现象看可能是邻区漏配。
但是从网络侧操作维护台查询服务小区邻区信息，查找到有邻区配置。如下图：
且源小区下发测量报告，因此不会是邻区漏配
2、再分析切换信令流程：根据网络配置，切换应该按下面流程交互：
查看网络侧跟踪的信令，在服务小区Uu跟踪可以看到，收到了UE的测量报告，再查看X2口，源
小区向目标小区发送了切换请求，并且收到目标小区的切换请求回应，最后在UU口下发了切换命令，
但没有收到UE的切换完成消息（站间切换）：
UU、X2口信令交互
eNB下发切换命令，但UE侧未收到切换命令，由此可以判断可能是空口出现传输质量问题。
3、再看空口无线质量，查看对应时间的RSRP值，发现在切换时间点附近服务小区的RSRP值出现陡降现象如下图：
从上图看，邻区比服务小区RSRP高1dB的情况维持了近两秒钟，但满足切换门限时服务小区
http://m.zhuodaoren.com/shenghuo331963/
推荐访问:rrc建立流程 rrc注册失败
