4、MAC层调度与随机接入：NPRACH前导设计、UE随机接入流程、HARQ重传机制、DRX省电模式
好，咱们今天聊MAC层。这一层在NB-IoT协议栈里，说白了就是个“交通指挥官”。它管着两件大事：一是你怎么接入网络，二是接入后怎么高效省电地传数据。我做了这么多年NB-IoT，发现很多工程师在物理层调得挺好，一到MAC层就翻车。嗯，今天咱们就把这几个硬骨头啃下来。
4.1 NPRACH前导设计：窄带里的“敲门砖”
先说说NPRACH。这是NB-IoT的物理随机接入信道。UE想跟基站说话，第一步就是发这个前导（preamble）。
前导的结构：它由4个符号组（symbol group）组成，每个组里有一个循环前缀（CP）和5个符号。这5个符号是重复的，说白了就是为了对抗覆盖差的环境。我在项目中遇到过，有些UE放在地下室，信号弱得可怜，全靠这重复机制才能让基站听清。
子载波间隔：NPRACH只用3.75kHz的子载波间隔。为什么这么窄？你想想看，NB-IoT带宽才180kHz，要支持大量UE同时接入，就得把频域切得细一点。3.75kHz意味着一个子载波只占这么点带宽，可以同时调度48个UE的前导。
前导格式：协议定义了两种格式：
| 格式 | CP长度 | 覆盖场景 |
|---|---|---|
| Format 0 | 66.7μs | 正常覆盖（≤144dB） |
| Format 1 | 266.7μs | 增强覆盖（≥144dB） |
Format 1的CP更长，能抗更大的时延扩展。我建议你在做深度覆盖场景时，优先考虑Format 1。不过代价是接入时间更长，功耗也更高。
关键参数：NPRACH的起始子载波由高层配置，通过SIB2-NB下发。UE根据自身覆盖等级选择对应的前导格式和重复次数。重复次数可以是1、2、4、8、16、32、64、128次。覆盖越差，重复越多。
4.2 UE随机接入流程：从“你是谁”到“你说话”
随机接入，就是UE跟基站建立连接的“握手”过程。NB-IoT用的是基于竞争的随机接入，流程分四步：
- Msg1：发送NPRACH前导。UE随机选一个前导序列，在指定的时频资源上发出去。这里有个坑：如果多个UE选了同一个前导，就会冲突。我在项目中遇到过，一个小区里几百个水表同时上报数据，冲突率飙升到30%。
- Msg2：随机接入响应（RAR）。基站检测到前导后，在DL-SCH上回复RAR。RAR里包含临时C-RNTI、定时提前量、上行授权等信息。UE要在RAR窗口内监听，窗口长度由高层配置，通常是2-10个子帧。
- Msg3：RRC连接请求。UE根据RAR里的上行授权，发送RRC连接请求。这个请求里包含UE的标识（TMSI或随机数）。如果冲突了，多个UE会同时发Msg3，基站就懵了。
- Msg4：竞争解决。基站回复竞争解决消息，包含UE的标识。UE收到后确认是自己的，就完成了接入。如果没收到，就退避重试。
避坑指南：我曾经调试过一个项目，UE总是接入失败。查了半天，发现是Msg2的RAR窗口配置得太短。UE在深度覆盖下，RAR传输需要重复很多次，窗口不够就收不到。后来我把窗口从5个子帧改到20个子帧，问题就解决了。
个人经验：随机接入的退避参数（backoff indicator）很关键。如果退避时间太短，冲突后马上重试，会加剧冲突。我一般建议退避时间设为20-40ms，给其他UE留出窗口。
4.3 HARQ重传机制：错了就重来，但别太频繁
HARQ，混合自动重传请求。NB-IoT用的是同步HARQ，说白了就是重传的时序是固定的，不需要额外信令。
HARQ进程数：NB-IoT支持最多2个HARQ进程。为什么这么少？因为NB-IoT数据量小，而且UE要省电。进程多了，UE得一直监听，功耗就上去了。
重传过程：UE发送数据后，在固定的时间点（通常是4个子帧后）监听ACK/NACK。如果收到NACK或没收到任何反馈，就在下一个HARQ周期重传。重传次数由高层配置，最多可以重传2048次。你没看错，2048次。这是为了应对极差覆盖。
冗余版本（RV）：每次重传可以用不同的冗余版本。RV0、RV1、RV2、RV3，循环使用。这样做的好处是，即使第一次传的数据全错了，重传时用不同的编码方式，还能拼凑出正确数据。我在项目中遇到过，有些UE在弱覆盖下，需要重传8次才能成功。这时候RV的循环就特别重要。
注意：HARQ的反馈时序是固定的。如果UE在深度覆盖下，基站发的NACK可能UE收不到。这时候UE会一直等，直到超时。我建议你把HARQ的定时器设得宽松一些，比如100ms，避免UE过早放弃。
4.4 DRX省电模式：让UE“睡个好觉”
DRX，不连续接收。这是NB-IoT省电的核心机制。UE不需要一直监听PDCCH，而是周期性地醒来看看有没有自己的数据。
DRX周期：由高层配置，范围从1.28秒到10.24秒。周期越长，UE越省电，但延迟也越大。我做过一个智能路灯项目，要求响应延迟小于2秒，所以DRX周期只能设到1.28秒。而水表项目，一天上报一次数据，DRX周期直接设到10.24秒，电池能用10年。
DRX参数：
- onDurationTimer：UE醒来后监听PDCCH的时间，通常是1-10个子帧。
- drx-InactivityTimer：如果UE在onDuration内收到调度，就延长监听时间。这个值一般设成0，因为NB-IoT数据量小，不需要长时间监听。
- drx-RetransmissionTimer：HARQ重传时的监听窗口。我建议设成2-4个子帧，够用就行。
eDRX（扩展DRX）：这是NB-IoT的杀手锏。eDRX周期可以长达40分钟甚至更久。UE在eDRX周期内大部分时间都在深度睡眠，只在寻呼窗口（PTW）内醒来。PTW的长度由高层配置，通常是1-10秒。
关键点：eDRX和PSM（省电模式）的区别。PSM是UE彻底休眠，连寻呼都不监听，直到TAU周期到了才醒来。eDRX是周期性醒来监听寻呼。如果你的应用需要下行可达，用eDRX；如果只做上行上报，用PSM更省电。
避坑指南：我曾经调试过一个项目，UE进入eDRX后，基站下发的数据总是收不到。查了三天，发现是核心网侧的eDRX参数没配好。UE的eDRX周期和核心网的寻呼周期必须对齐，否则寻呼消息就丢了。嗯，这个坑我踩过，你们别踩了。
个人建议：DRX参数的配置要结合业务场景。如果数据上报频率高，DRX周期设短一点；如果对延迟不敏感，就设长一点。我一般会先估算UE的功耗预算，再反推DRX参数。比如，一个电池容量1000mAh的设备，要求工作5年，那平均电流不能超过22μA。根据这个目标，再算DRX周期和eDRX周期。
好了，MAC层的这几个核心机制就聊到这儿。NPRACH是敲门砖，随机接入是握手，HARQ是纠错，DRX是省电。这四个东西配合好了，你的NB-IoT设备才能跑得稳、跑得久。下一章咱们聊RLC层，看看数据是怎么分段和重组的。