4. MAC层设计：调度器架构、HARQ机制、随机接入过程、逻辑信道优先级
好，咱们今天聊聊MAC层。说实话，MAC层是整个基站协议栈里最“忙”的层。它夹在物理层和高层之间，既要管资源分配，又要管重传，还得处理用户接入。我做了这么多年基站开发，MAC层出过的问题最多，也最考验工程师的全局思维。
咱们分四个核心模块来讲：调度器、HARQ、随机接入、逻辑信道优先级。每个模块我都会结合项目里的实际坑点来说。
4.1 调度器架构：核心中的核心
调度器是MAC层的大脑。它决定“谁在什么时候用什么资源发数据”。说白了，这就是个资源分配问题，但实时性要求极高——每个TTI（1ms）都要做一次决策。
我个人习惯把调度器分成三层：
- 时间域调度：先粗选，决定哪些用户有资格参与调度。比如根据CQI、缓存状态、优先级等，筛出一批候选用户。
- 频率域调度：在候选用户里做精细分配。把RB（资源块）分给最合适的用户，追求频谱效率最大化。
- 资源分配执行：把调度结果打包成DCI（下行控制信息），下发给物理层。
我在项目中遇到过一个问题：时间域调度做得太粗糙，导致高优先级用户经常被漏掉。后来我们加了个“紧急队列”，专门处理时延敏感的业务，比如VoIP。嗯，这个改动虽然小，但效果很明显。
调度器设计要点：
- 每个TTI的调度决策必须在0.5ms内完成，否则物理层来不及处理
- 调度算法要支持多种策略：轮询、最大C/I、比例公平（PF）
- 必须考虑HARQ重传的优先级——重传的优先级通常高于新传
你想想看，如果调度器设计不好，会出现什么情况？用户明明信号很好，但就是拿不到资源。或者重传一直失败，导致RLC层超时重传，整个链路就崩了。
4.2 HARQ机制：别让重传拖垮系统
HARQ（混合自动重传请求）是MAC层保证可靠传输的关键。它结合了前向纠错（FEC）和自动重传请求（ARQ）。说白了，就是第一次传错了，第二次传的时候把两次的数据合并起来解码，成功率更高。
HARQ有两种模式：
- 同步HARQ：重传发生在固定时刻。比如FDD LTE里，重传间隔固定为8ms。实现简单，但灵活性差。
- 异步HARQ：重传可以发生在任意时刻。调度器可以灵活安排，但需要额外的HARQ进程号来标识。
我记得有一次，我们在做TDD基站时，同步HARQ的固定时序和TDD的上下行配比冲突了。重传时刻正好落在下行时隙，结果数据发不出去。后来我们改成了异步HARQ，虽然实现复杂了点，但问题解决了。
避坑指南：
我曾经在HARQ进程管理上吃过亏。每个用户最多支持8个HARQ进程，但如果你把进程数设得太少，重传和新传就会互相阻塞。建议至少保留16个进程，尤其是高吞吐场景。
HARQ还有一个关键参数：最大重传次数。LTE里默认是4次，但我在实际测试中发现，对于边缘用户，4次重传往往不够。可以动态调整，比如根据BLER（误块率）来调整最大重传次数。
4.3 随机接入过程：用户的第一声招呼
随机接入是用户和基站建立连接的“第一声招呼”。它分为两种场景：
- 基于竞争的随机接入：多个用户可能同时发preamble，存在冲突风险。
- 基于非竞争的随机接入：基站给用户分配专用的preamble，没有冲突。
随机接入过程分四步：
- Msg1：用户发送preamble（前导码）。基站检测到preamble后，计算时间提前量（TA）。
- Msg2：基站回复随机接入响应（RAR），包含TA调整、临时C-RNTI、上行授权。
- Msg3：用户发送RRC连接请求（或调度请求）。
- Msg4：基站回复竞争解决消息，确认用户身份。
- 先按优先级从高到低遍历所有逻辑信道。
- 每个逻辑信道最多发PBR指定的数据量。
- 如果还有剩余资源，再按优先级从高到低继续发，直到资源用完。
- SRB（信令无线承载）优先级最高，PBR设大一些，保证信令及时发送
- VoIP等实时业务，PBR设成包大小，避免分片
- 背景流量（如FTP），优先级最低，PBR可以设小甚至为0
这里有个坑：preamble的检测成功率。我在项目中遇到过，小区边缘用户preamble功率太低，基站根本检测不到。后来我们做了个“功率爬坡”机制——用户第一次发preamble失败后，下次增加发射功率。嗯，这个机制在3GPP标准里也有，但实现细节得自己调。
注意事项：
随机接入的时延直接影响用户体验。如果preamble检测窗口设置得太短，用户可能来不及响应RAR。建议窗口长度至少覆盖10ms，尤其是覆盖半径大的小区。
还有一个容易被忽略的点：随机接入的资源分配。preamble占用的PRACH资源是固定的，如果配置得太少，高负载时用户接入会大量冲突。我建议根据小区用户数动态调整PRACH周期。
4.4 逻辑信道优先级：谁先谁后，得有规矩
逻辑信道优先级（LCP）解决的是“当多个逻辑信道都有数据要发时，谁先发”的问题。每个逻辑信道都有一个优先级值（1到16，1最高），还有PBR（优先比特率）和BSD（桶大小持续时间）。
LCP的执行流程是这样的：
说白了，就是“高优先级先吃，但也不能让低优先级饿死”。PBR就是保证低优先级信道至少能发一点数据。
我在项目中遇到过一个问题：VoIP的优先级设得很高，但PBR设得太小。结果VoIP数据包被拆成了好几段，每段都要等下一个TTI才能发，时延反而变大了。后来我们把PBR设成了VoIP包的大小，保证一个包能在一个TTI内发完。
LCP配置建议：
你想想看，如果LCP没配好，会出现什么情况？高优先级业务占用了所有资源，低优先级业务一直发不出去，RLC层超时重传，最终导致连接断开。嗯，我在现网里见过这种案例，排查起来特别痛苦。
小结
MAC层的这四个模块，每个都是环环相扣的。调度器决定资源分配，HARQ保证传输可靠性，随机接入解决用户接入，LCP确保业务优先级。任何一个模块出问题，都会影响整个系统的性能。
我个人建议，在做MAC层设计时，先把调度器和HARQ的交互理清楚。这两个模块的时序关系最紧密，也是最容易出bug的地方。随机接入和LCP相对独立，但配置参数需要根据实际场景反复调优。
好，今天就聊到这儿。下一章咱们讲RLC层，那个层也有不少有意思的坑。