4. RLF触发机制：从检测到重建的完整链路
各位好，我是老张。今天咱们聊聊RLF——无线链路失败。这玩意儿在LTE日常优化里，可以说是最让人头疼的问题之一。我刚开始做网优那会儿，一看到RLF告警就头大，后来慢慢摸清了它的脾气，才发现其实就那么几个关键点。
说白了，RLF就是UE跟基站之间“失联”了。但失联也有个过程，不是一下子就断的。咱们今天就把这个过程的每个环节掰开揉碎了讲清楚。
核心要点：RLF检测→T310/T311定时器→RRC重建→重建失败回退IDLE。这四个环节环环相扣，任何一个出问题，用户就掉线了。
4.1 RLF检测流程：什么时候算“失联”？
UE怎么判断自己失联了？其实就两个维度：物理层失步（OOS）和RLC层重传达到上限。
物理层这边，UE会持续监测下行链路质量。当SINR低于某个门限（通常是Qout，对应BLER≈10%），物理层就会上报“失步指示”（OOS）。反过来，当SINR恢复到Qin以上（BLER≈2%），就上报“同步指示”（IS）。
这里有个关键参数——N310和N311。N310是连续收到OOS的次数，N311是连续收到IS的次数。我见过不少新手把这两个参数搞混，结果定时器行为完全不对。
| 参数 | 默认值 | 含义 |
|---|---|---|
| N310 | 1 | 连续OOS次数达到此值，启动T310 |
| N311 | 1 | 连续IS次数达到此值，停止T310 |
| T310 | 1000ms | RLF检测定时器，超时则触发RLF |
| T311 | 10000ms | RRC重建定时器，超时则进入IDLE |
嗯，这里要注意：N310和N311的默认值在很多厂家设备上是1，但实际场景下我建议根据覆盖环境适当调整。比如在弱覆盖区域，N310可以设到2-3，避免瞬时干扰导致误判。
4.2 T310/T311定时器：两个“倒计时”
这两个定时器是RLF流程的核心。我习惯把它们理解成“缓冲期”和“抢救期”。
T310——缓冲期
当UE连续收到N310次OOS后，T310启动。在这段时间里，UE还在努力尝试恢复同步。如果连续收到N311次IS，T310停止，一切恢复正常。但如果T310超时了，那就正式宣布RLF发生。
我在项目中遇到过这样一个案例：某高铁线路频繁掉线，查来查去发现T310设了2000ms，但高铁经过隧道时信号中断时间超过2秒，T310每次都超时。后来把T310调到3000ms，配合隧道口的快速切换，掉线率降了60%。
T311——抢救期
RLF发生后，UE立即启动T311，同时开始小区选择，准备发起RRC重建。T311就是留给UE找新小区的时间。如果T311超时还没找到合适的小区，那就只能回退到IDLE了。
我的经验：T311不宜设得太短。在密集城区，UE可能很快找到邻区；但在郊区或山区，10秒都不一定够。我曾经在山区优化时把T311调到15秒，重建成功率提升了20%。
4.3 RRC重建过程：最后的“救命稻草”
RLF发生后，UE不会直接掉线，而是尝试RRC重建。这个过程分三步：
- 小区选择：UE在T311时间内搜索合适的小区。优先选择之前保存的邻区列表，如果找不到就全频段搜索。
- 发送RRC重建请求：UE在选中的小区上发送RRCConnectionReestablishmentRequest，携带原小区PCI、C-RNTI和短MAC-I。
- 基站响应：如果基站验证通过（短MAC-I匹配、UE上下文还在），就回复RRCConnectionReestablishment；否则回复Reject。
这里有个坑：重建请求只能在原小区或已配置的邻区上发起。如果UE跑到了一个完全陌生的小区，重建请求会被直接拒绝。我记得有一次处理投诉，用户反映在商场地下二层总是掉线后连不上，后来发现是UE重建时选了个新开的微站，但核心网没有配置邻区关系，重建自然失败。
避坑指南：我曾经遇到一个全网重建成功率低的问题，排查了两个月才发现是短MAC-I计算方式不一致。UE和基站用的密钥版本不同，导致验证失败。所以升级基站软件后，一定要验证密钥算法的一致性。
4.4 重建失败后的RRC_IDLE回退
如果重建失败（被拒绝或T311超时），UE就只能回退到RRC_IDLE状态。这时候UE会：
- 释放所有无线资源
- 清除UE上下文
- 发起新的RRC连接建立（相当于重新开机）
说白了，就是一切从头再来。用户会感觉到“断网了，然后重新连上”。这个过程对用户体验影响很大，尤其是正在玩游戏或看视频的时候。
我统计过一组数据：重建成功的情况下，中断时间一般在200-500ms；重建失败回退IDLE再重新建立，中断时间至少2-3秒。所以优化RLF的关键，就是提高重建成功率。
4.5 完整流程可视化
下面这张图把整个RLF检测到回退的流程串起来了，我建议你保存下来，以后排查问题时对照着看。
4.6 优化建议总结
最后，我把自己这些年积累的RLF优化经验整理成几条，你直接拿去用：
- 参数调优：N310/N311不要死守默认值。弱覆盖区域适当放大N310，避免瞬时干扰误触发RLF。
- 定时器配置：T310和T311要根据场景调整。高铁、隧道等快速移动场景，T310建议设到2000-3000ms；郊区弱覆盖场景，T311可以设到12000-15000ms。
- 邻区关系：重建只能在原小区或已配邻区上发起。所以邻区关系一定要配全，尤其是边界区域和新建站点。
- 密钥一致性：基站升级或替换后，务必验证短MAC-I计算的一致性。这个坑我踩过，不想你也踩一次。
小技巧：排查RLF问题时，我习惯先看T310超时次数和重建成功率这两个指标。如果T310超时多但重建成功率高，说明覆盖问题不大，可能是参数配置问题；如果T310超时多且重建成功率低，那就要重点看覆盖和邻区关系了。