上下行链路失步导致DPCH陡降问题说明

1、TD Tech Ltd. Doc Security Level: Internal Use Only上下行链路失步引起DPCH陡降问题说明1 DPCH陡降现象说明我们通过对比DPCH陡降的多个案例，发现目前项目上很多情况都是在切换过程中，上行或下行链路失步使得UE转入空闲态读取系统消息或者RNC下发RRC释放消息来主动释放链路，最终导致此业务发生DPCH陡降现象。1.1 案例1：硬切换时下行链路失步UE在做普通语音业务期间，上报测量报告希望进行切换。4.5s后UE小区搜索，读取系统消息，并做CellUpdate试图挽救（此过程在图中没有显示出来）。如下图所示，DPCH陡降发生时，UE已经处于读

2、取系统消息的时间。1.2 案例2：切换时上行链路失步UE在做普通语音业务期间，上报测量报告希望进行切换。8.5s后UE收到RNC下发的RRC连接释放消息，UE发送RRC连接释放完成消息，然后UE读取系统消息。DPCH陡降发生时，UE已经处于读取系统消息的时间。1.3 案例3：切换时上行链路失步UE在做普通语音业务期间，上报测量报告希望进行切换。收到RNC下发的RB重配命令后，UE上报RB重配完成消息。12s后UE进行小区搜索，读取系统消息。DPCH陡降发生时，UE已经处于读取系统消息的时间。2 DPCH陡降问题原因DPCH陡降发生在切换流程中，切换示例流程见下：从信令流程方面来分析硬切换空口失

3、败过程如下。l 与源小区下行失步：UE已发测量报告，但由于下行失步，收不到原小区DPCH数据，即收不到物理信道重配置信令（或RB重配置消息），导致无法切换；l 与目标小区上行失步：UE收到物理信道重配置消息，由于UpPCH存在干扰或FPACH信道的C/I或信号质量较差，UE不能在新小区建立上行同步，导致帧定时跟踪出现问题，这样UE无法在目标小区正确收发，发生切换失败。如果源小区的RL没有删除，RNC会通过源小区给UE下发物理信道重配失败（或RB重配失败），UE回到源小区，反之则发生掉话。l 与目标小区下行失步：UE收到物理信道重配置消息（RB重配置消息），由于原小区或周围邻小区对目标小区的下行

4、信号有较大的干扰，导致UE无法正确解析目标小区的下行信号，不能与目标小区建立同步，而引发物理信道重配置超时；发生掉话问题。l 与目标小区上行失步：UE已向目标NodeB发送物理信道重配置（RB重配置）完成信令，但是由于目标小区NodeB底噪过高，或此时多部UE位于小区边缘，且上行发射功率都被抬升的比较高，导致产生较大的上行时隙干扰，使得目标小区NodeB无法正确解析重配置完成的信令，而引发物理信道重配置超时。从切换的流程来看，上下行无线链路失步在切换过程中影响比较大，因此需要了解上下行无线链路失步的原理。2.1.1 下行无线链路失步准则处于CELL_DCH状态的UE，连续接收到来自物理层的N3

5、13个连续”our of sync”指示时，启动定时器T313，在此过程中若连续接收到来自物理层的N315个连续”in sync”指示，T313停止，否则T313超时，视为下行无线链路失步。2.1.2 下行无线链路失步后UE的行为UE检测到下行无线链路失步后，做如下处理：1) UE的RRC层向物理层下发“P_RRC_PHY_RL_Release_REQ”释放物理信道资源；2) 同时UE关闭上下行数据，并通过“P_RRC_PHY_CellSearch_REQ”原语让物理层进行小区的重搜，此时终端是无法测DPCH_RSCP值的，因此会在终端侧显示出DPCH陡降现象。3) 在搜到小区后，UE将在目标

6、小区上进行CellUpdate，原因为“radio link failure”。如果小区更新成功，则该次下行无线链路失步得到挽救，否则UE发生掉话。具体过程如下图所示：2.1.3 下行失步DPCH陡降的时长需要指出的是，各个终端厂家对于UE检测存在着或多或少的差异。下面列举的是某芯片厂商处理的情况。UE的物理层每隔一帧的时间（10ms），进行一次下行无线链路的同步情况的监测。在具体实施的过程中，UE侧采用滑窗的形式，滑窗的长度为160ms，滑窗每10ms移动一次。网络参数默认值N313=20，T313=3s，由此可以计算出UE收到第一个下行失步指示到DPCH陡降的时间为：DPCH陡降时长=16

7、0ms+N313*10ms+T313=3360ms2.1.4 上行无线链路失步准则在同步保持阶段，NodeB对于物理层两个连续同步指示的时间间隔为160ms，NB在收到N_OUTSYNC_IND个连续失步指示后，将启动“无线链路失败过程定时器”T_RLFAILURE，在收到N_SYNC_IND个同步状态指示后，NodeB将停止和复位T_RLFAILURE，如果T_RLFAILURE超时，NodeB则认为上行无线链路失步。2.1.5 上行无线链路失步后NodeB的行为NodeB检测到上行无线链路失步后，做如下处理：1) NodeB向RNC上发“Radio link failure indicat

8、ion”，指示同步失败。2) NodeB停发下行数据，目的是让UE下行失步，来上发CellUpdate。此时会在终端侧显示出DPCH陡降现象。3) RNC启动“收到RL失败等待定时器”。在该定时器超时前，如果未收到“Radio link restore”则RNC释放链路，并记为无线链路失败的掉话。2.1.6 上行失步DPCH陡降的时长网络参数默认值N_OUTSYNC_IND =20，T_RLFAILURE =5s。由此可以计算出，从第一上行失步开始到DPCH陡降的最短时间为：DPCH陡降时长=20*160ms+5000ms =8200ms3 DPCH陡降案例分析通过对上述DPCH陡降时间的计算

9、，结合我们前面所列的案例，从时长的角度进行分析如下：l 案例1：终端在15：51：09.814发送测量报告，在等了4.5秒后，在15：51：14.314 DPCH发生陡降，读取系统消息，并试图做小区更新。因此从时长的角度来看，终端是下行链路失步。l 案例2：终端在00：52：25.842发送测量报告，在等了将近8.7秒后，在00：52：34.532 DPCH发生陡降。因此从时长的角度来看，终端是上行链路失步。l 案例3：终端在23：03：06.873发送RB重配完成命令，在等了将近9秒后，在23：03：15.763 DPCH发生陡降，而后转入空闲态，并试图做小区更新。因此从时长的角度来看，终端是上行链路失步。总之，DPCH陡降在上下行链路失步时，是有很大发生可能性的，而且按照终端和基站设备对DPCH的处理机制也是合理的。4 DPCH陡降处理建议通过以上的分析，可以看到DPCH陡降和上下行无线链路失步有很大的关系，进而又和切换过程中的问题有着直接的联系，因此对DPCH陡降现象处理建议为：1. 先理顺切换关系，排除同频干扰，保证无线环境正常；2. 另可通过调整上行的SIR Target和DPCH