上行失步和下行失步

2、与目标小区下行失步：UE收到物理信道重配置消息（RB重配置消息），由于原小区或周围邻小区对目标小区的下行信号有较大的干扰，导致UE无法正确解析目标小区的下行信号，不能与目标小区建立同步，而引发物理信道重配置超时，发生掉话问题。
（物理信道重配置定时器不是一个3GPP协议定时器，它是各个厂家可以自己规定的私有定时器，在PHY RECONFIG 发送完毕后，RNC开始计时，当收到PHY RECONFIG COMPLETE以后，RNC停止计时。如果RNC超时，则会发生25.413里面的14号 IU REL REQ的掉话原因（当然，可能各厂家规定不一样），也有可能是46号掉话原因。
挽救措施：
UE检测到下行无线链路失步后，做如下处理：
1)UE的RRC层向物理层下发“P_RRC_PHY_RL_Release_REQ”释放物理信道资源；
2)同时UE关闭上下行数据，并通过“P_RRC_PHY_CellSearch_REQ”原语让物理层进行小区的重搜，此时终端是无法测DPCH_RSCP值的，因此会在终端侧显示出DPCH陡降现象。
引申：
上行失步DPCH陡降的时长：网络参数默认值N_OUTSYNC_IND =20，T_RLFAILURE =5s。由此可以计算出，从第一上行失步开始到DPCH陡降的最短时间为：DPCH陡降时长=20*160ms+5000ms =8200ms =8.2s
下行失步：UE侧检测
原因：
1、与源小区下行失步：UE已发测量报告，但由于下行失步，收不到原小区DPCH数据，即收不到物理信道重配置信令（或RB重配置消息），导致无法切换。
处理建议：
通过以上的分析，可以看到DPCH陡降和上下行无线链路失步有很大的关系，进而又和切换过程中的问题有着直接的联系，因此对DPCH陡降现象处理建议为：
1.先理顺切换关系，排除同频干扰，保证无线环境正常；
2.另可通过调整上行的SIR Target和DPCH的发射功率来改善上下行链路质量；
终端在00：52：25.842发送测量报告，在等了将近8.7秒后，在00：52：34.532 DPCH发生陡降。因此从时长的角度来看，终端是上行链路失步。
案例3：切换时上行链路失步
UE在做普通语音业务期间，上报测量报告希望进行切换。收到RNC下发的RB重配命令后，UE上报RB重配完成消息。12s后UE进行小区搜索，读取系统消息。DPCH陡降发生时，UE已经处于读取系统消息的时间。
2、与目标小区上行失步：UE已向目标NodeB发送物理信道重配置（RB重配置）完成信令，但是由于目标小区NodeB底噪过高，或此时多部UE位于小区边缘，且上行发射功率都被抬升的比较高导致产生较大的上行时隙干扰，使得目标小区NodeB无法正确解析重配置完成的信令，而引发物理信道重配置超时。（uncomplete）
3.再一个就是调整Uu口定时器参数，无线链路失步后，释放时间由T313、N313、N315 N_OUTSYNC_IND、T_RLFAILURE等参数控制。
4.关注UE，避免测试时间过长发热死机而影响测试结果。
Open Toolbar
终端在23：03：06.873发送RB重配完成命令，在等了将近9秒后，在23：03：15.763 DPCH发生陡降，而后转入空闲态，并试图做小区更新。因此从时长的角度来看，终端是上行链路失步。
总之，DPCH陡降在上下行链路失步时，是有很大发生可能性的，而且按照终端和基站设备对DPCH的处理机制也是合理的。
网络参数默认值N313=20，T313=3s，由此可以计算出UE收到第一个下行失步指示到DPCH陡降的时间为：DPCH陡降时长=160ms+N313*10ms+T313=3360ms=3.36s
【案例】
案例1：硬切换时下行链路失步
UE在做普通语音业务期间，上报测量报告希望进行切换。4.5s后UE小区搜索，读取系统消息，并做CellUpdate试图挽救（此过程在图中没有显示出来）。DPCH陡降发生时，UE已经处于读取系统消息的时间。
3)在搜到小区后，UE将在目标小区上进行CellUpdate，原因为“radio link failure”。如果小区更新成功，则该次下行无线链路失步得到挽救，否则UE发生掉话。
引申：需要指出的是，各个终端厂家对于UE检测存在着或多或少的差异，下面列举的是某芯片厂商处理的情况。
UE的物理层每隔一帧的时间（10ms），进行一次下行无线链路的同步情况的监测。在具体实施的过程中，UE侧采用滑窗的形式，滑窗的长度为160ms，滑窗每10ms移动一次。
3)RNC启动“收到RL失败等待定时器”。在该定时器超时前，如果未收到“Radio link restore”则RNC释放链路，并记为无线链路失败的掉话。（NodeB——RNC）
（注释：上行失步需要基站来检测，也有类似于UE侧的定时器和计数器，一旦发现上行失步，则NodeB会上报RL Failure Indication（NBAP信令）给RNC，同时RNC会启动相应的无线链路失败等待定时器，定时器超时则发起Iu Release Request，记为一次掉话。）
）
判断标准：处于CELL_DCH状态的UE，连续接收到来自物理层的N313个连续”out of sync”指示时，启动定时器T313，在此过程中若连续接收到来自物理层的N315个连续”in sync”指示，T313停止，否则T313超时，视为下行无线链路失步。（下行失步主要原因为无线环境不好，干扰，弱覆盖等，下行失步会cellupdate，而且一般可以恢复通话正常。）
上行失步和下行失步
上行失步：基站侧检测
原因：
1、与目标小区上行失步：UE收到物理信道重配置消息，由于UP存在干扰或FPACH信道的C/I或信号质量较差，UE不能在新小区建立上行同步，导致帧定时跟踪出现问题，这样UE无法在目标小区正确收发，发生切换失败。如果源小区的RL没有删除，RNC会通过源小区给UE下发物理信道重配失败（或RB重配失败），UE回到源小区，反之则发生掉话。（上行同步失败）
判断标准：
在同步保持阶段，NodeB对于物理层两个连续同步指示的时间间隔为160ms，NB在收到N_OUTSYNC_IND个连续失步指示后，将启动“无线链路失败过程定时器”T_RLFAILURE，在收到N_SYNC_IND个同步状态指示后，NodeB将停止和复位T_RLFAILURE，如果T_RLFAILURE超时，NodeB则认为上行无线链路失步。（上行失步会删除链路，立即断开，造成UE最终掉话。）
终端在15：51：09.814发送测量报告，在等了4.5秒后，在15：51：14.314 DPCH发生陡降，读取系统消息，并试图做小区更新ห้องสมุดไป่ตู้因此从时长的角度来看，终端是下行链路失步。
案例2：切换时上行链路失步
UE在做普通语音业务期间，上报测量报告希望进行切换。8.5s后UE收到RNC下发的RRC连接释放消息，UE发送RRC连接释放完成消息，然后UE读取系统消息。DPCH陡降发生时，UE已经处于读取系统消息的时间。
挽救措施：
NodeB检测到上行无线链路失步后，做如下处理：
1)NodeB向RNC上发“Radio link failure indication”，指示同步失败。（NodeB——RNC）
2)NodeB停发下行数据，目的是让UE下行失步，来上发CellUpdate。（注：此时会在终端侧显示出DPCH陡降现象。）