第4章时域结构

4. 时域结构：OFDM符号、时隙与子帧对延迟的影响

各位做基带的朋友，咱们今天聊聊时域结构。说白了，就是OFDM符号、时隙和子帧这三个东西，到底怎么影响你的数据延迟。

我记得刚接触5G NR的时候，第一反应是：这玩意儿比LTE复杂太多了。LTE就那么一个子帧长度，NR倒好，参数集一换，啥都变了。嗯，咱们今天就把这个理清楚。

5G NR定义了一个基本时间单位，叫Tc。公式我就不写了，你记住一个关键点：Tc = 0.509 ns。为什么是这么个奇怪的值？因为要兼容LTE的时序，同时支持更高的频率和带宽。

我刚开始做RTL实现的时候，看到这个0.509ns，心想这玩意儿在硬件里怎么对齐？后来发现，其实你不用纠结这个绝对值，关键是理解它怎么推导出OFDM符号长度。

关键结论：Tc决定了所有时域参数的基准。子载波间隔越大，OFDM符号越短，延迟越低。

OFDM符号是时域上最小的调度单位。你想想看，一个数据包从进入基带到发射出去，至少得等一个完整的OFDM符号周期。

不同参数集（Numerology）下，OFDM符号长度差异很大：

参数集 μ	子载波间隔 (kHz)	OFDM符号长度 (μs)	CP长度 (μs)
0	15	66.67	4.69
1	30	33.33	2.34
2	60	16.67	1.17
3	120	8.33	0.59

看到没？μ=3的时候，一个符号才8.33微秒。μ=0的时候，要66.67微秒。差了整整8倍。

我在项目中遇到过一个场景：做URLLC业务，要求端到端延迟小于1ms。如果用μ=0，光一个OFDM符号就占了66微秒，再加上处理延迟、传输延迟，根本压不住。后来我们果断切到μ=2或μ=3，符号短了，延迟就下来了。

个人习惯：做延迟预算的时候，我一般先把OFDM符号长度算清楚。这是最底层的物理限制，你算法再快，也得等一个符号发完。

一个时隙包含14个OFDM符号（常规CP下）。时隙长度 = 14 × OFDM符号长度。

所以：

时隙是调度的基本单位。基站给UE分配资源，最少就是一个时隙。这意味着什么？意味着你的数据从到达基站到被调度出去，最少要等一个时隙的边界。

我曾经踩过一个坑：做下行调度器的时候，没考虑时隙对齐的等待时间。结果仿真出来的延迟比预期多了半个时隙。后来加上这个等待时间，才跟实测对上。嗯，这里要注意，调度延迟不是你处理完就能发，得等到下一个时隙的起始位置。

子帧在NR里是个固定值：1ms。不管参数集怎么变，子帧长度不变。一个子帧包含多少个时隙？取决于μ：

子帧的作用是什么？我个人的理解是：它提供了一个绝对的时间参考。不管你的参数集怎么变，1ms就是1ms。这对于HARQ重传、周期性的测量报告、系统信息的调度，都非常重要。

注意：子帧虽然是固定1ms，但它的边界跟时隙边界不一定对齐。μ=2的时候，一个子帧里有4个时隙，每个时隙0.25ms。你设计状态机的时候，千万别把子帧和时隙的边界搞混了。

咱们把这三个东西串起来看。一个数据包从进入基带到发射出去，经历的时域延迟包括：

其中，第2和第3项是物理层协议决定的，你没法绕过。所以，选择参数集的时候，要综合考虑业务需求。

举个例子：做eMBB业务，对延迟不敏感，可以用μ=0，符号长，覆盖好。做URLLC，必须用μ=2或μ=3，符号短，延迟低。但代价是什么？子载波间隔大了，符号短了，CP也短了，对多径的容忍度下降。

避坑指南：我曾经在一个项目里，为了追求极致低延迟，选了μ=3。结果在郊区场景下，CP太短，多径干扰严重，误码率飙升。后来不得不回退到μ=2，在延迟和性能之间找了个平衡点。

下面这张图，是我自己总结的时域结构对延迟的影响关系。你看一眼就明白了：

这张图把整个逻辑串起来了。你从OFDM符号出发，到参数集的选择，再到延迟的各个组成部分，最后落到总延迟。做系统设计的时候，按这个思路走，基本不会漏掉关键点。

时域结构对延迟的影响，说白了就是三个层次：

我个人建议，做延迟分析的时候，先把参数集定下来，然后算清楚每个时域单位的长度。再结合你的处理流水线，就能估算出比较准确的延迟了。

嗯，这一节就到这儿。记住一句话：时域结构是延迟的物理天花板，你算法再牛，也突破不了这个限制。