4G&5G专题-97：MAC层- 调度 - 下行调度算法实战：从优先级计算到RB资源映射

1. 下行调度算法实战全景图

想象一下基站调度器就像个忙碌的交通指挥中心，每毫秒（TTI周期）都要处理上百辆"数据卡车"的通行请求。我参与过多个4G/5G基站项目，最头疼的就是如何在1毫秒内完成从数据优先级判定到资源分配的完整决策链。这里用个生活场景类比：调度器相当于快餐店经理，要在30秒内决定哪些顾客优先取餐（HARQ重传用户）、给每人分配多少食材（RB资源）、用什么包装盒（MCS调制方式）。

典型的下行调度包含四个关键阶段：

• 优先级计算：区分VIP客户（控制信令）和普通顾客（业务数据）
• 用户选择：从排队人群中筛选最需要服务的对象
• MCS确定：根据顾客距离（信道质量）选择外卖包装方式
• RB分配：将厨房有限的食材合理分配给各个订单

实测中，20MHz带宽下单个TTI要处理约100个RB的分配，整个过程必须在900μs内完成，留给每个阶段的决策时间不足250μs。下面我就拆解这个"毫秒级决策艺术"的完整流程。

2. 优先级计算：谁先获得服务权

2.1 数据类型的优先级排序

基站待发数据就像急诊室里的病人，必须严格分级处理。根据3GPP标准，优先级从高到低依次为：

1. 系统消息：相当于医院广播（如SIB1），必须全局优先
2. HARQ重传：类似复诊患者，超过最大重传次数就会丢包
3. RRC信令：好比病历调取请求，影响用户连接状态
4. GBR业务：视频通话这类"危重病人"，需要保证最低速率
5. Non-GBR业务：普通网页浏览这类"门诊患者"

在华为某基站实测中，HARQ重传占比约15%时，系统吞吐量会下降23%。因此我们采用动态权重算法：

python复制def calculate_priority(data_type, retry_count):
    base_priority = {
        'system_info': 100, 
        'harq': 80 + retry_count*5,
        'rrc': 70,
        'gbr': 50,
        'non_gbr': 30
    }
    return base_priority[data_type]

2.2 用户级优先级处理

完成数据类型筛选后，还要在同类用户间二次排序。常见算法有：

• 轮询(Round Robin)：公平但效率低，实测吞吐量下降40%
• 最大载干比(Max C/I)：偏好信道好的用户，边缘用户会"饿死"
• 正比公平(PF)：平衡瞬时速率与历史平均速率

以PF算法为例，其核心公式为：

code复制优先级 = 当前可达速率 / 历史平均速率 * QoS权重

在某城市密集区测试显示，PF算法使得小区边缘用户速率提升65%，而中心用户仅下降12%。

3. 用户选择与MCS确定

3.1 基于CQI的动态适配

信道质量指示(CQI)就像用户发来的"信号自拍"，取值范围0-15。在爱立信某次外场测试中：

• CQI=15（64QAM）时单RB速率达5.5Mbps
• CQI=8（16QAM）时降至2.1Mbps
• CQI=4（QPSK）时仅有0.7Mbps

CQI到MCS的转换需要三步：

1. 查表确定调制阶数：QPSK/16QAM/64QAM
2. 计算有效码率：剔除冗余校验比特
3. 选择TBS索引：根据可用RB数反推传输块大小

python复制# CQI到MCS的典型转换逻辑
def cqi_to_mcs(cqi):
    if cqi >= 13:
        return {'modulation':'64QAM', 'code_rate':0.92}
    elif cqi >=7:
        return {'modulation':'16QAM', 'code_rate':0.61} 
    else:
        return {'modulation':'QPSK', 'code_rate':0.3}

3.2 MCS的保守策略

实际项目中我们发现，直接采用CQI建议的MCS会导致15%的重传率。更稳妥的做法是：

1. 取最近5次CQI的移动平均值
2. 在信道快速衰落时自动降阶
3. 对GBR业务保留10%的余量

某运营商测试数据显示，采用保守MCS策略后：

• 重传率从12.3%降至5.7%
• 用户平均体验速率仅下降8%
• 视频卡顿次数减少62%

4. RB资源映射实战

4.1 资源分配三剑客

RB（Resource Block）是调度的最小单位，每个RB包含12个子载波×7个符号。三种分配方式对比如下：

Type1的独特优势在于：

• 通过交织分配获得频率分集增益
• 20MHz带宽下分4个子带，每个子带包含约25个RB
• 用3bit开销指示子带位置（相比Type0节省17%信令）

4.2 动态分配算法

在实际编码中，RB分配要考虑：

1. 频域冲突：避免相邻RB分配给信道质量差异大的用户
2. 时域延续：为VoIP等业务保留固定位置RB
3. 功率平衡：控制每个RB的EPRE（每RE能量）

中兴某基站采用的动态分配伪代码：

python复制def allocate_rb(users):
    for u in sorted(users, key=lambda x: -x.priority):
        if u.qos_type == 'GBR':
            allocate_contiguous_rb(u)  # Type2
        else:
            if u.channel_variance > threshold:
                allocate_distributed_rb(u)  # Type1 
            else:
                allocate_rbg(u)  # Type0

5. 调度器的性能调优

5.1 关键参数配置

根据诺基亚实测数据，推荐参数组合：

• PF算法的公平性因子：0.7-0.9之间
• HARQ最大重传次数：3次（超过后切换MCS）
• CQI滤波窗口：快速移动场景用3，静止场景用7
• RB分配阈值：GBR业务保留20%的备用RB

5.2 典型问题排查

踩过几次坑后总结的常见问题：

1. 吞吐量骤降：检查CQI上报周期是否被误设过长（建议≤20ms）
2. 用户不调度：确认AMBR限速策略是否过严
3. RB利用率低：调整Type0/Type1的使用比例（密集城区建议6:4）

在某地铁站优化案例中，通过将PF算法的alpha参数从0.5调整到0.8，使得高峰时段用户平均速率提升39%，而系统吞吐量仅损失7%。