无线通信重传为何越打越堵？HARQ时序怎么配？

误块一上来，系统不是慢慢降速，而是越重传越堵，这种现象往往不只是空口差，而是反馈闭环放大。无线通信链路在 HARQ 场景下最怕的，不是偶尔重传，而是进程数和时序预算没有覆盖真实往返时延。

HARQ 的价值在于把首次译码失败变成可恢复事件，但前提是系统手里要有足够并行进程，让等待 ACK 的时间不会把发射端直接晾空。进程数太少时，链路一旦拉长往返时延，前面的块还在等反馈，后面的调度就无块可发；此时空口看起来并不满，吞吐却已经被协议空转吃掉。尤其在长时延回传或卫星类场景里，这个问题会比纯物理层误码更早出现。

很多实现把 HARQ 进程数按标称 RTT 设计，却忽略了排队、加解密、分段重组和跨处理器搬运也会吞时间。只要实际反馈路径比预算多出几个时隙，原本刚刚够用的并行度就会突然变成卡脖子。现场常看到的一类症状是 BLER 不算特别高，吞吐却出现台阶式掉落，本质上就是协议管线先断流了。

重传时序的难点，还在于它会和自适应调制互相牵制。若重传间隔太长，信道状态早已变了，第一次发送所基于的 MCS 假设不再成立；若间隔太短，接收端软合并和缓存整理又可能来不及完成。对无线通信系统而言，这意味着 HARQ 不是越快越好，而是要让调度、软合并窗口和反馈可靠性处在同一节奏上。

队头阻塞会把问题进一步放大。某个块迟迟等不到确认，后续高优先级数据也可能因为顺序约束被压在后面，最终从链路层堵到业务层。若系统只盯平均 BLER，不看重传队列深度和反馈超时分布，就会误以为是空口偶发变差，实际上协议已经进入拥塞自激状态。更合理的做法，是让调度能够识别长反馈路径上的高风险块，提前降低其首次发送激进度。

排查这类问题时，单看空口频谱和物理层日志远远不够。要把每个传输块的发送时刻、ACK 返回时刻、进程占用、软缓存状态和最终业务时延串起来，才能知道堵点究竟在空口、基带处理，还是反馈链路。只要时间轴一拉直，很多“随机拥堵”都会显出稳定的协议原因。

软合并缓存的大小也会反过来限制策略选择。进程数一多、码块一长，接收端需要保留的软信息会迅速膨胀；缓存不够时，只能提前丢弃低优先级块或限制并发重传，结果又把理论上的 HARQ 增益打折。把缓存预算、RTT 和目标峰值吞吐联动设计，才能避免协议层想并发、实现层却装不下的矛盾。

ACK 可靠性本身也别当成理所当然。反馈比特若在边缘场景下偶发翻转，发送端会把成功块错当失败，或把失败块误判为成功，前者导致重复占用，后者直接放大上层重排压力。把反馈信道的保护强度一起算进 HARQ 设计，才能避免闭环被最短那条消息拖垮。

所以，越打越堵往往不是重传机制本身无效，而是并行进程和反馈时序没有给它留出工作空间。把 HARQ 的时间账和缓存账一起算清，链路才不会在误码升高时先把自己堵死。