《上下行链路失步导致dpch陡降问题说明》由会员分享，可在线阅读，更多相关《上下行链路失步导致dpch陡降问题说明（7页珍藏版）》请在金锄头文库上搜索。
1、2018-3-14第 1 页, 共 7 页上下行链路失步引起DPCH陡降问题说明1 DPCH 陡降现象说明陡降现象说明我们通过对比DPCH陡降的多个案例，发现目前项目上很多情况都是在切换过程中，上行或下行链路失步使得UE转入空闲态读取系统消息或者RNC下发RRC释放消息来主动释放链路，最终导致此业务发生DPCH陡降现象。1.1案例 1：硬切换时下行链路失步UE在做普通语音业务期间，上报测量报告希望进行切换。4.5s后UE小区搜索，读取系统消息，并做CellUpdate试图挽救（此过程在图中没有显示出来）。如下图所示，DPCH陡降发生时，UE已经处于读取系统消息的时间。1.2案例 2：切换时上行
2、链路失步UE在做普通语音业务期间，上报测量报告希望进行切换。8.5s后UE收到RNC下发的RRC连接释放消息，UE发送RRC连接释放完成消息，然后UE读取系统消息。DPCH陡降发生时，UE已经处于读取系统消息的时间。2018-3-14第 2 页, 共 7 页1.3案例 3：切换时上行链路失步UE在做普通语音业务期间，上报测量报告希望进行切换。收到RNC下发的RB重配命令后，UE上报RB重配完成消息。12s后UE进行小区搜索，读取系统消息。DPCH陡降发生时，UE已经处于读取系统消息的时间。2018-3-14第 3 页, 共 7 页2 DPCH 陡降问题原因陡降问题原因DPCH陡降发生在切换流程
3、中，切换示例流程见下：从信令流程方面来分析硬切换空口失败过程如下。与源小区下行失步：UE已发测量报告，但由于下行失步，收不到原小区DPCH数据，即收不到物理信道重配置信令（或RB重配置消息），导致无法切换；2018-3-14第 4 页, 共 7 页与目标小区上行失步：UE收到物理信道重配置消息，由于UP存在干扰或FPACH信道的C/I或信号质量较差，UE不能在新小区建立上行同步，导致帧定时跟踪出现问题，这样UE无法在目标小区正确收发，发生切换失败。如果源小区的RL没有删除，RNC会通过源小区给UE下发物理信道重配失败（或RB重配失败），UE回到源小区，反之则发生掉话。与目标小区下行失步：UE收
4、到物理信道重配置消息（RB重配置消息），由于原小区或周围邻小区对目标小区的下行信号有较大的干扰，导致UE无法正确解析目标小区的下行信号，不能与目标小区建立同步，而引发物理信道重配置超时；发生掉话问题。与目标小区上行失步：UE已向目标NodeB发送物理信道重配置（RB重配置）完成信令，但是由于目标小区NodeB底噪过高，或此时多部UE位于小区边缘，且上行发射功率都被抬升的比较高，导致产生较大的上行时隙干扰，使得目标小区NodeB无法正确解析重配置完成的信令，而引发物理信道重配置超时。从切换的流程来看，上下行无线链路失步在切换过程中影响比较大，因此需要了解上下行无线链路失步的原理。2.1.1下行无
5、线链路失步准则处于CELL_DCH状态的UE，连续接收到来自物理层的N313个连续”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”原语让物理原语让物理层进行小区的重搜，此时
6、终端是无法测层进行小区的重搜，此时终端是无法测DPCH_RSCP值的，因此会在终端侧显示值的，因此会在终端侧显示2018-3-14第 5 页, 共 7 页出出DPCH陡降现象陡降现象。3)在搜到小区后，UE将在目标小区上进行CellUpdate，原因为“radio link failure”。如果小区更新成功，则该次下行无线链路失步得到挽救，否则UE发生掉话。具体过程如下图所示：2.1.3下行失步 DPCH 陡降的时长需要指出的是，各个终端厂家对于UE检测存在着或多或少的差异。下面列举的是某芯片厂商处理的情况。UE的物理层每隔一帧的时间（10ms），进行一次下行无线链路的同步情况的监测。在具体
7、实施的过程中，UE侧采用滑窗的形式，滑窗的长度为160ms，滑窗每10ms移动一次。网络参数默认值N313=20，T313=3s，由此可以计算出UE收到第一个下行失步指示到DPCH陡降的时间为：DPCH陡降时长=160ms+N313*10ms+T313=3360ms2.1.4上行无线链路失步准则在同步保持阶段，NodeB对于物理层两个连续同步指示的时间间隔为160ms，NB在收到N_OUTSYNC_IND个连续失步指示后，将启动“无线链路失败过程定时器”T_RLFAILURE，在收到N_SYNC_IND个同步状态指示后，NodeB将停止和复位T_RLFAILURE，如果T_RLFAILURE超
8、时，NodeB则认为上行无线链路失步。2.1.5上行无线链路失步后 NodeB 的行为NodeB检测到上行无线链路失步后，做如下处理：1)NodeB向RNC上发“Radio link failure indication”，指示同步失败。2)NodeB停发下行数据，目的是让停发下行数据，目的是让UE下行失步，来上发下行失步，来上发CellUpdate。此时会在终端。此时会在终端2018-3-14第 6 页, 共 7 页侧显示出侧显示出DPCH陡降现象陡降现象。3)RNC启动“收到RL失败等待定时器”。在该定时器超时前，如果未收到“Radio link restore”则RNC释放链路，并记为无
9、线链路失败的掉话。2.1.6上行失步 DPCH 陡降的时长网络参数默认值N_OUTSYNC_IND =20，T_RLFAILURE =5s。由此可以计算出，从第一上行失步开始到DPCH陡降的最短时间为：DPCH陡降时长=20*160ms+5000ms =8200ms3 DPCH 陡降案例分析陡降案例分析通过对上述DPCH陡降时间的计算，结合我们前面所列的案例，从时长的角度进行分析如下：案例1：终端在15：51：09.814发送测量报告，在等了4.5秒后，在15：51：14.314 DPCH发生陡降，读取系统消息，并试图做小区更新。因此从时长的角度来看，终端是下行链路失步。案例2：终端在00：5
10、2：25.842发送测量报告，在等了将近8.7秒后，在00：52：34.532 DPCH发生陡降。因此从时长的角度来看，终端是上行链路失步。案例3：终端在23：03：06.873发送RB重配完成命令，在等了将近9秒后，在23：03：15.763 DPCH发生陡降，而后转入空闲态，并试图做小区更新。因此从时长的角度来看，终端是上行链路失步。总之，DPCH陡降在上下行链路失步时，是有很大发生可能性的，而且按照终端和基站设备对DPCH的处理机制也是合理的。2018-3-14第 7 页, 共 7 页4 DPCH 陡降处理建议陡降处理建议通过以上的分析，可以看到DPCH陡降和上下行无线链路失步有很大的关系，进而又和切换过程中的问题有着直接的联系，因此对DPCH陡降现象处理建议为：1.先理顺切换关系，排除同频干扰，保证无线环境正常；2.另可通过调整上行的SIR Target和DPCH的发射功率来改善上下行链路质量；3.再一个就是调整Uu口定时器参数，无线链路失步后，释放时间由T313、N313、N315 N_OUTSYNC_IND、T_RLFAILURE等参数控制。4.关注UE，避免测试时间过长发热死机而影响测试结果。
