载噪比为何雨天先塌？余量怎么留？

晴天指标一切正常，雨带一过链路就先松掉，这说明系统最薄的地方并不在额定功率，而在天气余量。载噪比遇雨先塌，通常不是一个参数偏了，而是衰减和噪声温升在同一时刻一起作用。

降雨对高频卫星和微波链路最直接的影响，是让传播路径上的有效衰减突然增加。水滴并不会只把载波轻轻压低，它会按照频段、极化和降雨强度对传播造成附加损失，Ka和高Ku频段尤其明显。链路预算若只按晴空自由空间损耗加一个经验折扣去做，遇到强降雨时载波会先明显下滑，而接收端参考噪声水平却不会同步下降，于是裕量几乎是瞬间被吃掉。

更容易被漏算的是天空噪声温度抬升。雨云和湿大气不仅衰减信号，也会以更高等效温度向天线馈入噪声，接收系统看到的不只是“信号少了”，而是“噪声多了”。这就是为什么有些链路实测退化比单纯雨衰分贝值还更难看，因为分子被压低的同时，分母也被悄悄放大了。

余量设计因此不能只看最坏月平均值，还要看业务希望保住的可用度。若目标是广播级连续业务，几分贝雨衰余量远远不够；若任务允许短时降码或切到低阶调制，则可以把一部分极端天气风险交给自适应机制。问题在于，这种取舍必须在系统设计阶段写清楚，而不是现场掉链后再临时决定要不要牺牲吞吐量。

仰角和站点地理条件也会改写边界。低仰角意味着穿越降雨层的路径更长，海边、热带和山区的降雨统计分布又完全不同。同样标称的设备搬到不同地区，余量需求可能差出数分贝甚至更多。只拿实验站数据复用到所有站点，是雨天链路失守最常见的管理错误。

可用的工程手段通常有三类：上行功率控制，在允许的线性和EIRP边界内顶住一部分衰减；自适应编码调制，让业务先降速保链不断；站点分集或路径分集，把同一场降雨同时击穿两条链路的概率降下来。每种手段都不是免费的，前者会挤占功放余量，中者牺牲容量，后者增加系统复杂度，但至少它们是在主动分配天气风险，而不是被动等天吃链路。

验证余量是否够用时，不能只看一张理论预算表。应把本地降雨统计、目标可用度、接收门限以及功控/降码策略联合仿真，再用历史强降雨事件做回放校核。只要模拟结果和已知天气日的退化幅度对不上，就说明预算里还有一项环境变量没有进账。

很多链路在中雨时还能靠功控顶住，到了短时暴雨却先被功放回退或监管限值卡死。若这些边界不提前写进策略，现场看起来就像系统“突然失灵”，其实只是可调用余量早已被别的约束吃完。

对运营团队来说，最好把不同雨强下应切换的功控档位、降码门限和告警动作预先写成脚本。天气一来再人工判断，往往来不及在门限跌穿前完成收敛。

把天气风险转成可执行阈值，通常比事后复盘哪一场雨更有工程价值。

因此，载噪比在雨天失守时，真正该补的不是一句“天不好”，而是把雨衰和噪声温升一起算进余量。链路只在晴天成立，等于没有真正成立。