5.2 调度算法
5.2 调度算法
本节摘要：调度器每毫秒决定资源块归谁。轮询绝对公平但效率垫底，最大 C/I 效率最高但边缘用户饿死，比例公平（PF）用"瞬时速率除以历史均值"的负反馈居中平衡，成为 LTE 与 5G 的默认基线。本节手推三种算法的优先级公式，再用一段可运行的仿真把结论变成数字，最后看 QoS 感知调度如何叠加时延约束。
承接 5.1 的闭环框架，本节把镜头对准判决中心里最重要的那个盒子。读懂这一节，你就读懂了"为什么同一张网，有人快有人慢"的全部制度原因。
三种分蛋糕规则
轮询（RR）：排队叫号，人人轮一遍。优先级与信道状态无关，实现最简单。问题是对快慢用户一视同仁——给信道差的用户一个资源块只能装几十字节，同样的块给信道好的用户能装几百字节，系统总吞吐量被拖累。
最大 C/I：谁信道好给谁（C/I 即载波干扰比）。数学上可以证明这是最大化瞬时总吞吐量的贪心最优。但信道好的用户（通常离基站近）会长期霸占资源，小区边缘用户可能永远排不上队——效率的极致，公平的灾难。
比例公平（PF）：优先级 = 当前可达速率 除以 近期平均吞吐量。精妙之处在负反馈：某用户被调度后平均吞吐量上升、优先级自动回落；长期没被调度则均值下降、优先级自动回升。长期看每个用户获得近似相等的时间份额，而每个份额又尽量落在各自信道的高峰——公平占用时间，效率利用时机。
手推一遍公式
设用户 i 在时刻 t 的瞬时可达速率为 r_i(t)（由 CQI 查表得到），近期平均吞吐量为 T_i(t)（时间常数 t_c 的指数滑动平均）。PF 每次调度取优先级最大者：
优先级 P_i(t) = r_i(t) / T_i(t)
被调度后更新：T_i = (1 - 1/t_c) × T_i + (1/t_c) × r_i
t_c 是个关键旋钮：太短（如几十个 TTI），均值跟踪瞬时值，PF 退化为轮询；太长（如几十秒），均值几乎不动，边缘用户的"均值下降带来的优先级回升"来得太慢，饥饿时间超出业务容忍。工程取值通常落在数百到数千 TTI（LTE 中约 100 至 2000 毫秒量级）。
理论上 PF 还有个漂亮的身份：当用户数足够多时，最大化长期总对数吞吐量（每用户吞吐量取对数再求和）的最优解恰是 PF——对数效用对低吞吐量用户敏感，这正是"比例公平"名字的由来。
把结论跑成数字
PF 的机会主义收益主要来自频域多用户分集：同一个毫秒里，不同资源块上的衰落各不相同，逐块挑"此刻谁最划算"就能白捡增益。下面这段程序模拟三个位置不同的用户、十个资源块在三种规则下的长期表现，可以直接运行：
import random random.seed(11) users = ["近点用户", "中点用户", "边缘用户"] means = {"近点用户": 6.0, "中点用户": 3.0, "边缘用户": 1.0} RB, N, TC = 10, 30000, 1000 # 资源块数 仿真毫秒数 平均时间常数 def simulate(rule): served = {u: 0 for u in users} avg = {u: 0.3 for u in users} for t in range(N): # 每个资源块独立抽样一次衰落（均值乘 0.1 到 2.0 的随机起伏） rates = {u: [means[u] * random.uniform(0.1, 2.0) for _ in range(RB)] for u in users} inst = {u: 0 for u in users} for rb in range(RB): if rule == "RR": pick = users[(t + rb) % 3] elif rule == "MAXCI": pick = max(users, key=lambda u: rates[u][rb]) else: # PF：逐资源块比较 瞬时速率除以平均吞吐量 pick = max(users, key=lambda u: rates[u][rb] / avg[u]) served[pick] += rates[pick][rb] inst[pick] += rates[pick][rb] for u in users: avg[u] = (1 - 1 / TC) * avg[u] + (1 / TC) * inst[u] total = sum(served.values()) return total, [served[u] / total * 100 for u in users] for rule in ["RR", "MAXCI", "PF"]: total, shares = simulate(rule) name = {"RR": "轮询", "MAXCI": "最大CI", "PF": "比例公平"}[rule] print(f"{name:<6}总吞吐 {total/1000:7.1f} Gbit 份额 近点{shares[0]:5.1f}% 中点{shares[1]:5.1f}% 边缘{shares[2]:5.1f}%") # 实际输出： # 轮询 总吞吐 1051.1 Gbit 份额 近点 60.0% 中点 30.0% 边缘 10.0% # 最大CI 总吞吐 2010.6 Gbit 份额 近点 85.7% 中点 14.1% 边缘 0.2% # 比例公平 总吞吐 1525.6 Gbit 份额 近点 60.0% 中点 30.0% 边缘 10.0%
三行输出各有一句台词。最大 C/I 吞吐最高，但边缘用户份额被压到 0.2%，等于出局；轮询人人有份，可惜整个频段轮流整块发放，白白放弃了"这块资源此刻对谁最划算"的信息；PF 逐资源块地利用这份信息，吞吐比轮询高约 45%、拿到最大 C/I 方案的约 76%，而三类用户的份额结构与轮询完全一致。用不到四分之一的峰值代价，换回完整的公平结构，外加近一半的免费增益——频域多用户分集就是 LTE 把调度粒度做到资源块级的原因。
图：PF 调度的时间线——机会落在谁的头上
叠加 QoS：从公平到守约
PF 解决了"公平地抢机会"，但守不了时约——等 500 毫秒对网页无所谓，对语音和工业控制是灾难。工程上的做法是在 PF 之上叠三层约束：GBR 优先，语音承载的优先级恒高于数据承载（除非其保证速率已满足）；时延感知，包的等待时间越长优先级越高，思想同操作系统的最早截止期优先；配额封顶，为每个 QoS 等级设置资源份额上限，防止某类业务过载殃及全网。5G 的 5QI 体系把业务等级细化到数十种，调度器在同一毫秒里要同时伺候"求快"的 URLLC、"求稳"的语音、"求多"的下载——这正是第 8 章三大场景共存的技术前线。
⚠️ 常见坑：看到小区平均吞吐量高就认为调度没问题。平均数会骗人——把 PF 的时间常数调得过长，平均值漂亮，边缘用户的瞬时饥饿却足以让实时业务掉线。评估调度要同时看均值与低分位（如边缘用户 5% 吞吐量）。
本节要点回顾
- 三种规则：轮询公平低效、最大 C/I 高效不公平、PF 用负反馈取得平衡，公式为瞬时速率除以历史均值。
- 时间常数：t_c 过短退化为轮询、过长造成饥饿，典型数百至数千 TTI。
- 仿真结论：逐资源块的 PF 比整载波轮询多拿约 45% 吞吐（频域多用户分集），同时保持份额结构不变。
- QoS 叠加：GBR 优先、时延感知、配额封顶——现代调度器是"PF 打底、约束封顶"的分层建筑。