《针对上行同步导致的rlc链路异常的问题解决方案建议.docx》由会员分享，可在线阅读，更多相关《针对上行同步导致的rlc链路异常的问题解决方案建议.docx（2页珍藏版）》请在金锄头文库上搜索。
1、针对上行同步导致的针对上行同步导致的 RLC 链路异常的问题解决方案建议链路异常的问题解决方案建议Luscious.Li 问题现象问题现象：上行同步调调整带来的 RLC 链路异常，接着上行长时间处于是同步状态，从而引起的小区重选，根据我们 4.29 的 log 也看到，发生小区重选之前我们的 TA 就已经异常了。此 TA 的异常不是由于下行的调整导致的，而是持续接收到网络侧的 SS=0，而 ZTE 的说法是，他们在判断上行失同步之后就会下发 SS=0，这样很容易引起 UE 上行信号发送异常。解决思想解决思想：我们是否应该在长时间接收到 SS=00 的时候提前启动小区重选呢？以防止失步时间过长而
2、导致掉话，这个涉及到测量上报的问题RLC 不可恢复错误等而引起的小区重选是 RLC 在发送/接收数据的时候发生了错误，并且通过本身的机制都已经无法恢复的情况。这时候的邻近小区列表的来源是：SIB11（系统消息 11），SIB12（系统消息 12）和测量控制消息。在这种情况下，一旦触发重选，就需要尽快的选择到一个合适的小区去驻留，以避免因为扫频、搜索小区和繁重的测量而占用大量 UE 的资源和损耗大量的时间。RRC 只能尽量利用已知的邻近小区列表，尽量利用已经有的测量值。处理流程：处理流程：根据“尽量利用已经有的测量值”的原则，RRC 需要设计一个大的结构变量s_rrc_measurementRe
3、sult，来记录邻近小区（包括服务小区）的小区描述以及对应的测量结果。因为，无论是在空闲模式还是连接模式的 FCH 和 PCH 状态下，总是会进行周期性的测量的；而在 FCH 和 DCH 下更要根据网络的“测量控制消息”来进行一系列的测量。因此可以说，这个结构在通常的情况下，都是能够保存有测量值的。但是与此同时，使用这个结构里面的测量值也存在一定的风险性，这个风险性就在于这个测量值的有效性和生命期。当过了它可使用的生命期，这个测量值显然就不能再认为有效了，在这个基础上得到的结论也肯定是不可靠的。为了控制这个风险，采取了两个措施：第一、是该结构变量只保存最新的测量值，即每收到一次新的测量值就对这
4、个结构进行一次更新，使它能反应最近的小区的质量；第二、当 RRC 连接建立完成从空闲模式进入连接模式之后，将对这个变量清一次零。也就是说，空闲模式下的测量结果，其有效性只是到 RRC 连接建立为止。当完全进入连接模式后，就只能使用连接模式下的测量值了。这样，当重选发生而需要使用测量值的时候，就以小区描述（frequency，sync，midamble）为索引，将这个结构变量 s_rrc_measurementResult 里面的测量值与前面构建好的邻近小区列表进行一一的对应，筛选出有测量值的小区，再进行一些简单的处理，以形成可用的重选列表。根据参数“Intrafrecellresel”进行侯选
5、列表的筛选。需要注意的是：此时，在筛选处理之后，需要对服务小区的测量值再进行一点特殊的处理：人为的将服务小区的测量值降低几个 dBm，降低后再和其他小区放在一起去统一排序形成重选小区列表。这样做的内在原因在于：之所以会发起重选这个过程，正是因为在当前的小区上已经发生了一些问题（无线链路失败或者 RLC 不可恢复错误等），所以人为将当前小区的优先级降低，如果有质量差不多的其他小区存在，则优先选择到其他小区去驻留。当重选列表形成时，则依次试着去驻留列表中的小区，成功驻留后，则重选结束。当然，连接模式下的重选后面常常会紧接着一个原因为“小区重选”的小区更新过程。通过这个过程，UE 告之网络，自己驻留的小区已经发生了变化。这一系列的行为，配合上切换等过程，共同实现了 RRC 的连接移动性过程。
