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