说起5G的无线帧我总觉得它是整个NR体系里最容易被跳过、但又最不该跳过的一块。当年我第一次啃协议的时候也是先看了一大堆物理层概述、频段划分、带宽配置等真正遇到时隙配比、SSB位置、下行调度错位这些具体问题时才回过头来把帧结构重新捋了一遍。那种感觉就像是先学了开车再回头补交规——能用但心里没底。这次就接着上次的架构往下走把无线帧这一层拆开揉碎讲清楚它到底由哪些单位构成、为什么5G要设计成这么灵活、这些数字在网优和排障现场又是怎么用上的。不管你是刚入行的通信新人还是从LTE转过来的老手只要碰过5G基站调测、邻区优化或者路测分析这篇都能给你补上一块结实的底层认知。1. 无线帧为什么值得单独拎出来学刚开始接触5G的时候很多人的注意力都会放在速率怎么这么高天线怎么这么多这类显性的指标上帧结构这种偏底层的东西往往被一笔带过。但真到了现场你就会发现几乎每一个和时序相关的现象溯源都能追到帧结构这里。小区搜索搜的是SSB在帧里的固定位置随机接入看的是PRACH occasion落在哪个时隙TDD系统的上下行配比直接决定了同一个帧里的资源怎么切甚至连邻区之间的干扰很多时候都是两边帧配比没对齐闹出来的。我印象最深的一次是帮一个园区场景排查上行覆盖异常。表面看是上行解调门限偏高折腾了好几天以为是功率控制或者干扰问题最后翻配置才发现是两个相邻小区一个用了4:1的上下行配比、另一个用了8:2帧内上下行边界没对齐互相踩脚。这事要是对帧结构没概念光盯着功率参数看能绕进去一周。所以无线帧这东西学的时候觉得是名词解释用起来全是诊断依据。另外一点5G的帧结构跟LTE最大的不同在于灵活性。LTE时代的帧结构基本是焊死的子载波间隔固定15kHz一个子帧1ms、两个时隙TDD/FDD各有各的模板你没什么可调的。5G就不一样了子载波间隔从15kHz一路给到240kHz一个帧里时隙数量随子载波间隔变化时隙内部的符号还能分下行、上行、灵活三类。这种设计自由度带来了能力也带来了复杂度——配置没配好问题比LTE还隐蔽。先把这套框架的意义搞清楚后面所有关于调度、配比、SSB的讨论才有落脚点。2. 帧、子帧、时隙、符号这套单位的换算关系2.1 为什么5G还要保留10ms一帧这个老约定先说最顶层。5G NR的无线帧时长仍然是10ms这一点和LTE完全一致。很多人会问都重新设计空口了为什么还沿用10ms我的理解是两点考虑。第一后向兼容和网络协同的需要——5G和LTE在相当长一段时间里是共站、共频谱、互为邻区的关系帧长一致能让两套系统在时序上有一个共同的节拍器双连接、切换、干扰协调这些跨制式操作才不会处处对不齐。第二10ms这个量级对很多上层应用来说是个合适的调度粒度既不会太粗导致调度不灵活也不会太细导致信令开销压不住。在10ms的无线帧之下NR定义了一个子帧subframe时长固定1ms。注意子帧在NR里更多是一个参照系的角色真正承载调度和配置的基本单位是时隙slot。子帧存在的价值主要是给一些绝对时间参数比如测量周期、定时器粒度、系统消息的修改周期提供一个稳定的时间锚点。你可以把子帧理解成尺子上的厘米刻线它本身不一定用来画图但没有它很多描述就没法统一口径。而每一帧里到底有多少个子帧永远是10个每个1ms。这个不会随子载波间隔变化。会变的是每个子帧里塞进了多少个时隙——这正是5G灵活性的核心来源。2.2 时隙和符号才是真正干活的单位时隙slot是NR调度的基本时间单位一个时隙包含14个OFDM符号常规循环前缀CP的情况下符号是时域上最小的可调度单元。这里有个容易搞混的点LTE时代常规CP下一个时隙是7个符号一个子帧有2个时隙合计14个符号。5G把一个时隙14个符号直接定死不再拆成两个7符号的时隙。这么做的好处是调度粒度更规整也简化了时隙格式的设计。时隙的长度不是固定的它随着子载波间隔SCS变化。具体关系可以用一个叫numerology的参数μ来描述子载波间隔等于 15kHz × 2^μ。μ0时子载波间隔15kHz一个时隙就是1ms一个子帧刚好1个时隙。μ越大子载波间隔越宽单个符号越短时隙也就越短一个子帧里能装下的时隙就越多。换算公式其实很直观每帧的时隙数 10 × 2^μ每子帧的时隙数 2^μ。我把常用档位整理成一张表方便你一眼对上号。μ子载波间隔每子帧时隙数每帧时隙数单时隙时长每时隙符号数015 kHz1101 ms14130 kHz2200.5 ms14260 kHz4400.25 ms14扩展CP时为123120 kHz8800.125 ms144240 kHz161600.0625 ms14这张表建议直接背下来或者说存成手机壁纸。因为你后面看任何配置、任何日志时隙编号和子帧编号的换算全靠它。比如一条信令里说DCI在slot 5调度你得知道对于30kHz来说这是第3个子帧附近的资源再比如SSB的配置读出来是一串符号编号判断它在帧里的绝对位置也得靠这张表。2.3 符号的时域构成CP到底占了多少再往下钻一层一个OFDM符号并不是纯有用信号它前面挂了一小段循环前缀CP。CP的作用是抵抗多径时延扩展代价是占掉了一部分时域资源。以15kHz为例一个有用符号的长度是1/15000≈66.67μs常规CP下第一个符号的CP约5.2μs其余符号的CP约4.69μs。14个符号加起来大致是 5.2 13×4.69 14×66.67 ≈ 1ms正好凑满一个时隙。这就是为什么一个15kHz的时隙恰好等于1ms——符号数、CP长度和采样率是三边同时对上的结果。你可能注意到第一个符号的CP更长这个细节。这是为了让整个时隙严格对齐到1ms边界属于一种设计上的微调。在换算绝对时间、做时序对齐的时候如果精度要求到微秒级这个差异是要考虑进去的但在日常网优里符号级精度通常够用了除非你在做高精度同步或者时间敏感类业务的分析。3. 灵活子载波间隔背后的取舍逻辑3.1 为什么5G不再只用一个15kHzLTE时代15kHz几乎是唯一选择好处是简单坏处是一招鲜吃遍天在很多新场景下不够用。5G要面对的场景跨度极大既有低频广覆盖的宏站也有毫米波的高容量热点既有要求大带宽的业务也有要求低时延的业务。不同场景对子载波间隔的诉求正好相反这才逼出了多numerology的设计。核心矛盾在于相位噪声和多普勒频移。子载波间隔越窄同样的频率误差占一个子载波的比例就越大频偏和相位噪声就越容易造成子载波间干扰。频率越高相位噪声越严重多普勒频移也越大——所以高频段必须用更宽的子载波间隔来稀释这些误差。这就是为什么FR2毫米波频段普遍用120kHz甚至240kHz而低频FR1常用15kHz和30kHz。反过来说子载波间隔越宽符号越短同样的CP时长下能对抗的多径时延扩展就越小相对而言CP占比也更敏感。所以低频、多径丰富的环境更适合窄子载波间隔。这不是谁取代谁而是各管一段按频段和场景分工。3.2 CP开销和采样率这笔账如果只看子载波间隔越大越好这个直觉你会觉得干脆全用240kHz算了。实际不行因为CP开销和实现复杂度会咬你。子载波间隔放宽符号变短但CP长度如果不变那么CP在符号里占的比例就上升了频谱效率下降。为保持效率宽子载波间隔下CP也要相应缩短可它需要对抗的多径在低频场景又没那么严重这本身就是一笔平衡账。采样率方面NR以1.92MHz为基准乘以2^μ得到对应档位的基础采样率再往上还要考虑FFT点数和带宽配置的匹配。工程师在做链路预算或者容量估算的时候如果需要精确到资源粒子RE级别这些都得算进去。日常配置里你不用手算设备会帮你处理但知道这背后的逻辑你在看一些为什么这个档位不支持这个带宽的限制时就不会一头雾水。3.3 FR1和FR2在帧结构上的分工把上面的逻辑落到具体频段就形成了比较清晰的分工。FR1大致410MHz到7.125GHz以15kHz和30kHz为主覆盖和移动性优先适合广域组网FR2大致24.25GHz以上以120kHz为主少数场景用240kHz容量和带宽优先适合热点补容。60kHz这个档位则相对特殊在FR1里可以用于特定TDD配置在FR2里也能见到灵活性比较强但配置时对同步和保护间隔的要求也更讲究。这个分工不是拍脑袋定的而是频率越高、地物遮挡越敏感、越倾向于视距传播、越依赖波束成形这一整条逻辑推导出来的。理解了这条线你在做站址规划或者频段选型讨论的时候就能说清楚为什么某个场景推荐某个numerology而不是只会背结论。4. 时隙格式与TDD配比现场最常动手的地方4.1 下行、上行、灵活三类符号的角色一个时隙内部的14个符号并不都是同一个方向。NR把它们分成三类下行符号D、上行符号U和灵活符号F。下行符号只能用于下行传输上行符号只能用于上行灵活符号则可以根据实际调度需要临时充当下行或上行——它的存在就是为了让TDD系统在时隙级别能快速适配流量方向的变化。TDD系统里上下行共用同一段频谱靠时间切分所以哪几个符号是下行、哪几个是上行这件事直接决定了系统的行为。如果全网配比一致、边界对齐那很干净一旦邻区之间不一致就会在边界处互相干扰。这也是我前面提到那次园区排查的根因所在。常见的配比形式比如D D D F U这种描述意思是前面几个时隙偏下行中间一个特殊时隙用于上下行切换后面一个偏上行。不同的业务模型需要不同的配比下行视频类业务多就配得更偏下行上行回传类业务多就适当加大上行比重。这不是固定值是要根据业务画像去调的。4.2 半静态TDD-UL-DL-Config的配置逻辑NR给了两条配置路径半静态配置和动态配置。半静态配置对应TDD-UL-DL-ConfigCommon和TDD-UL-DL-ConfigDedicated这类参数负责给出一个长期基线它规定了参考子载波间隔、一个配比周期内有多少个下行时隙、多少个上行时隙、特殊时隙的符号怎么排。动态配置则通过DCI里的时隙格式指示SFI在基线之上做短期调整应对瞬时的流量变化。这两层的设计意图很清楚半静态负责稳保证小区间的时序关系和参考信号、公共信道的传输有确定的落点动态负责活让调度能跟上业务波动。配置过程中最容易出问题的是参考子载波间隔的选取。因为配比周期、时隙偏移这些参数都是以某个参考SCS为基准描述的你如果选了一个和实际业务SCS不一致的参考值算出来的上下行边界就可能跟预期差一截。我在配置时习惯先把参考SCS和配比周期在纸上画出来对齐一遍再下发避免来回改。4.3 邻区配比不一致引发的排查链路回看那次园区问题完整链路是这样的现象是某小区上行底噪抬升、上行解调质量下降初判是外部干扰用扫频确认又没有明显的外部源再查本小区功率控制参数正常最后把两个相邻小区的帧配比拉出来对比发现上下行切换点错开了一个时隙A小区在某个符号上行发射的时候B小区正好在那个符号下行发射互踩。解决方案是统一参考SCS和配比周期、对齐切换点。这个排查思路可以复用到很多类似场景只要是干扰存在但找不到明确外部源、且发生在小区边界的疑难杂症都值得先怀疑帧配比。排查顺序建议是先确认是不是外部干扰扫频再看本小区参数最后做邻区配比横向比对。另外提醒一句改配比是牵一发动全身的操作不是随便调的改之前最好确认周边邻区的配置和业务分布改完还要看切换成功率有没有波动。5. SSB在无线帧里的位置小区搜索的入口5.1 SSB的时域图案不是随便摆的同步信号块SSB由PSS、SSS和PBCH组成占用4个连续OFDM符号、频域上20个资源块240个子载波。小区搜索、小区选择、波束扫描全都依赖它。SSB在一帧里的位置是协议规定好的图案跟频段范围和子载波间隔强相关。我把常用的几种图案归到一张表里。注意这里的Case对应的是不同的SCS和频段组合符号编号是相对SSB突发集起始点而言的。场景典型SCSSSB起始符号位置示例一个突发集内最大SSB数低频FR13GHz以下15 kHz{2, 8} 14nn0,14中频FR13-6GHz30 kHz{4, 8, 16, 20} 28nn0,18FR2 毫米波120 kHz{4, 8, 16, 20} 28nn0,1,2,364FR2 毫米波240 kHz{8, 12, 16, 20, 32, 36, 40, 44} 56n64这些图案背后有几个约束在起作用一是要和PSS/SSS/PBCH的复用关系对上二是要给波束扫描留出足够的SSB数量FR2因为要用窄波束SSB数量多三是要让UE在初始搜索时不需要知道太多先验信息就能找到。SSB突发集的周期常见的是5ms或10ms的倍数具体配置里叫SSB周期。5.2 SSB位置怎么影响接入和优化你可能觉得SSB位置是协议定死的改不了。位置本身确实定死但SSB的周期、SSB波束的配置、以及SSB所在的时隙和TDD配比之间是否协调是可以配置的。这就带来一个实战要点SSB的时域位置必须和TDD上下行配置兼容SSB是下行信号它落的位置必须在下行符号或者灵活符号上不能落在纯上行符号里。如果配比配得让某些SSB时隙变成了上行UE就搜不到这个波束直接导致接入困难或者波束覆盖空洞。在优化现场我见过因为SSB周期配得过长、导致接入时延大、切换不及时的案例也见过SSB和邻区撞在同一批时频资源上、造成同频串扰的。排查这类问题的思路是先看SSB配置周期、波束数量、时域位置再对照TDD配比确认没有落在上行符号最后看邻区的SSB规划有没有冲突。这比盲目调功率有效得多。6. 把这些知识落到排障和路测现场6.1 接入类问题的帧结构排查入口接入失败、随机接入成功率低这类问题帧结构相关的排查入口其实就几个。第一随机接入occasionRO落在哪个时隙、哪个符号和该时隙的上下行属性是否匹配——如果RO被配到了上行符号上那是对的方向如果配到了下行或大多数是下行的时隙里就要看看是不是配置错误。第二前导序列preamble的格式。前导的格式决定了它的序列长度和占用的时域长度不同格式覆盖的距离和抗频偏能力不同。长格式和短格式各自有不同的序列长度配置理论上长格式覆盖更远、对频偏更宽容短格式则更适合低时延、高频偏场景。选错格式轻则接入时延大重则根本接不进去。第三随机接入的时序和帧号、子帧号、时隙号是绑定的UE是根据系统消息里的配置计算出RO的绝对位置的。如果配置和小区实际使用的numerology不匹配UE算出来的位置就是错的接入自然失败。我在排查时的一个习惯是把UE侧算出来的RO位置和基站侧配置的位置分别列出来对一遍往往会直接暴露问题。6.2 定时器与帧时序的关联很多信令流程里的定时器看着和帧结构没关系其实底座就是帧时序。你仔细想定时器的计时单位要么是子帧、要么是时隙在SCS不同的情况下换算成绝对时间是不一样的。同样是若干时隙的超时值30kHz和120kHz下对应的绝对时间差了4倍。这在跨numerology的场景比如双连接、切换里尤其容易出问题——一端按自己的SCS理解超时另一端按另一套理解时序就对不上。排查这类问题时我的做法是先把涉及的定时器值统一换算到绝对时间毫秒级再判断是否真的和现场观察到的行为一致。如果换算之后还是对不上那说明问题不在帧结构本身而是别处比如处理时延、调度延迟或者信令丢失。这一步换算能帮你快速排除掉一大半看起来像帧问题的疑点。6.3 路测和优化中怎么用好帧结构做路测分析的时候帧结构是你解读log的底层坐标系。每个采样点的时间戳背后是某个帧号、子帧号、时隙号一次小区搜索、一次测量上报、一次切换触发都能对应到具体的时域位置。当你在log里看到某个异常行为集中出现在特定的时隙模式上比如每逢特殊时隙就出问题那方向基本就锁定了——去查特殊时隙的配置和它周边的调度。优化侧也一样。做时隙配比调整、SSB波束优化、PRACH资源规划的时候帧结构是共同的参照系。团队的沟通里如果能统一用帧-子帧-时隙-符号这套语言描述位置排查效率会高很多。我以前遇到团队里有人只说第几分钟那种描述在跨设备对比时基本没法用还得回头去换算浪费时间。7. 我踩过的几个坑和几条实用建议第一个坑是想当然按LTE的时隙去理解NR的时隙。LTE的时隙是7个符号、0.5ms一子帧两个时隙NR的时隙直接14个符号长度随SCS变。刚转过来的时候我看到时隙两个字就条件反射按0.5ms算结果在30kHz场景里算错了整整一半。后来我强迫自己养成习惯看到时隙先问一句哪个SCS下的再动手换算。第二个坑是配比周期和参考SCS不对应。半静态TDD配置里的那些周期、偏移量都是绑在参考SCS上的。有一次我改参考SCS没同步改配比周期结果本小区的上下行切换点和理论值偏了虽然没闹出大干扰但调度效率肉眼可见地下降。后来我的做法是改任何一个和帧结构相关的参数之前先在纸上把所有相关参数按参考SCS推一遍确认自洽再下发。第三个坑是忽略扩展CP的存在。常规CP下时隙14个符号但扩展CP下是12个符号而且扩展CP主要用在60kHz这类特定场景比如某些回传或特定覆盖需求。如果配置里用了扩展CP符号数就不能按14算时隙内的符号分配、SSB位置这些都会受影响。这个坑不算常见但只要撞上一次就够呛建议遇到60kHz相关配置时多留个心眼。分享几个日常能用的小技巧。一是把常见SCS对应的时隙-符号-绝对时间换算做成一张随身小抄或者表格工具网优时随手查比临时心算靠谱。二是排查干扰问题时把先扫频、再查本区、后比邻区作为固定顺序避免一上来就闷头调参数。三是分析log时凡是异常的时域聚集现象先想想是不是落在特殊时隙或者SSB时隙上这个直觉能帮你省很多时间。最后一点做帧配比调整一定要在业务低谷期做并且提前想好回退方案因为这类改动的影响面往往是跨小区的。这套东西说到底就是一层一层往下对齐10ms的帧是总框架1ms的子帧是参照尺时隙跟着子载波间隔变符号是最后干活的。把这层关系理顺了后面不管是看调度、读信令还是做优化心里都会踏实很多。下次我们再往物理层更深处走把这些时间单位里到底装了哪些信道、哪些参考信号再拆开看看。