★ FEATURED ARTICLE 5G进入规模商用这几年绝大多数从业者的日常其实是围着参数配置和优化指标转频段选在哪个NR频点这波用户的下行体验怎么提升PDSCH的RB数够不够用TDD帧结构配比会不会造成上行受限……但说实话只要你接触过NR的优化或开发早晚会遇到这样一个场景拿着测试终端做信令分析看到PCell配置了一堆BWP脑子第一反应是“这玩意儿到底怎么切来切去的”或者拿着无线帧结构图核对上下行配比却对时隙里的符号分配一头雾水。这些问题追到底全都指向同一个基础——NR的整体传输结构。这篇文章就打算把这个底子聊透。它是【5G无线接入技术系列】的第五篇专门拆解NR的传输结构从参数集设计、帧结构、频域资源到物理信道与信号的映射规则再到一次真实数据传输在结构上是怎么跑通的。我把这套内容写得尽量贴合一线工程师的实际使用场景也会把很多“为什么这样设计”的门道讲清楚而不是直接把3GPP规范丢给你。适合刚入门5G优化的测试工程师、做终端协议栈的研发同学以及所有想把NR物理层真正看明白的人。1. 先理解一个根本变化NR为什么要把子载波间隔做成可配置要聊NR传输结构第一把钥匙不是帧结构也不是RB怎么定义而是参数集。3GPP在NR里定义了灵活可变的参数集核心是子载波间隔SCSSub-Carrier Spacing的变化。而整个NR的时频资源排布、时隙长度、符号时长、最大信道带宽全都跟这个参数绑在一起。1.1 子载波间隔为什么是传输结构的“底层开关”LTE时代子载波间隔是固定的15kHz整个系统都围绕这个值构建简单但不够灵活。到了NR因为要同时支撑eMBB增强移动宽带、URLLC低时延高可靠和mMTC海量机器通信这三类差异巨大的场景一个固定的子载波间隔根本没法同时满足“大带宽、低时延、广覆盖”的需求。所以NR引入了可配置的SCS取值包括15kHz、30kHz、60kHz、120kHz等。子载波间隔一变很多东西联动变化子载波间隔变大符号长度变短时隙长度跟着变短单位时间内能塞进的时隙数量变多这让空口传输的“心跳”更快时延更低子载波间隔变大符号时长变短循环前缀CP时长也变短抗多径干扰的能力下降因此大SCS通常配合更好的信道环境使用子载波间隔变大每个RB占用的带宽增大RB始终是12个子载波一个载波能容纳的RB总数变少这对大带宽配置下的资源调度有直接影响。打个比方LTE像是一班固定时刻表的绿皮车速度恒定、班次固定NR则像高铁调度系统可以按线路需求调整发车间隔赶时间的线路上车次更密覆盖广的线路上单次容量更大。1.2 15kHz到120kHz每个数字背后的使用场景主流的SCS选择有四个子载波间隔符号长度含CP约时隙长度主要使用场景15kHz71.4μs1ms与LTE共存、广覆盖、低频FDD频段30kHz35.7μs0.5ms3.5GHz等中频TDD频段的主流配置60kHz17.9μs0.25ms高频非授权场景或特殊覆盖需求120kHz7.8μs0.125ms毫米波高频段超大带宽、极低时延实际网络中最常用的组合是Sub-6GHz和3.5GHz中频段用30kHz毫米波用120kHz。国内5G中频主力频段如3.5GHz普遍配置30kHz的SCS原因很直接在这个频段既要保证单载波带宽能到100MHz又要兼顾覆盖和时延均衡。如果选15kHz时隙太长低时延场景吃亏如果选60kHz往上CP太短覆盖能力下降明显。30kHz是当前中频段最稳的折中。这里有个实操经验可以分享我们做网络优化时排查一个区域的时延问题不要只看核心网或传输侧首先就要去确认当前小区的SCS配置。不同SCS下调度周期的基本粒度都不一样10ms无线帧里能容纳的时隙数量直接从10个变成20个时延表现完全不同。这是NR传输结构里最底层、也最容易被忽视的一个变量。2. 时间维度从无线帧到符号NR的帧结构到底怎么排的理解了参数集之后下一步就是时间轴上的排布。NR的时间结构其实延续了LTE的基本框架但时隙和符号的定义方式变了变得更加灵活尤其体现在TDD模式的上下行配比上。2.1 无线帧、子帧和时隙三层关系别记混NR的时间结构分四层无线帧10ms一个一个无线帧分为两个半帧每个半帧5ms子帧1ms一个一个无线帧内10个子帧时隙由7个或14个符号组成正常CP下为14个符号时隙长度跟SCS直接相关符号时频资源的最小时间单位承载调制后的真实数据。上面任何一层跟SCS的关系都不用死记记住一个公式即可每子帧时隙数 子载波间隔 / 15kHz。比如SCS15kHz每子帧1个时隙无线帧内10个时隙SCS30kHz每子帧2个时隙无线帧内20个时隙SCS120kHz每子帧8个时隙无线帧内80个时隙。由此也能推出SCS越大时隙粒度越细调度器能“切分”时间的能力越强。30kHz下一个时隙0.5ms如果采用7符号的短时隙调度URLLC业务还能拿到更细的资源粒度但这种短时隙在实际网络中用的不是很多常规业务还是以完整时隙为基本调度单位。2.2 时隙里的符号和上下行分配TDD配比的核心在TDD模式下一个时隙里的符号不会全部用于下行或者全部用于上行而是可以灵活分配。NR在时隙级别定义了灵活符号可以动态配置为下行D、上行U或灵活Flexible可后续被动态信令改写为D或U。常见的一个30kHz TDD时隙配比2.5ms双周期DDDSU长这样第1个时隙D D D D D D D D D D D D D D14个下行符号第2个时隙D D D D D D D D D D D D D D14个下行符号第3个时隙D D D D D D D D D D D D D D14个下行符号第4个时隙D D D D D D D D D D D D D D14个下行符号第5个时隙D D D D D D D D D D D D U U U U前10个符号下行最后4个符号上行用作上行探测和短上行业务这种配比的上下行比例大约是4:1对应的单用户下行体验更好上行因为只有1个完整时隙的时长容易成为瓶颈。很多5G用户反映“上行慢、上传文件卡”跟TDD帧结构的配比设计有很大关系尤其是在中频TDD组网的场景下上行时隙占比偏少是大范围存在的客观物理限制不是网络故障却最容易被用户感知。做优化的时候要特别留意一个点TDD配比跟邻区必须一致。如果两个同频邻区的上下行时隙配比不同它们之间的交叉时隙会产生严重的干扰下行时隙干扰上行接收最后双双掉吞吐。这在多厂家设备共存的区域尤其明显联调时第一件事就是拉通双方的帧偏置和时隙配比。2.3 帧偏置和上下行切换点被忽视的体验大杀器除了配比本身帧偏置Frame Offset同样关键。不同厂家的基站如果帧起始偏置不一致就算上下行配比一样两个小区在时间上还是错位交叉时隙干扰依然存在只不过变成“隐性”的。排查5G上行干扰时如果PRB级干扰底噪抬升有明显的固定图案一个高概率原因就是TDD帧不对齐。我们实际处理过的几个投诉热点最后都是靠全网统一帧偏置参数解决的。说到上下行切换NR里还有一个“保护间隔”概念。TDD上下行切换之间需要一个GPGuard Period来缓冲信号传播时延和收发转换时间GP太短远点用户的上行信号还没到基站基站就已经切到下行GP太长浪费时频资源。实际优化中广覆盖的郊区站点GP配置一般要留足城区的密集站点可以配短一些。这都属于传输结构在时间维度上的精细化运营。3. 频域维度资源栅格、RE/RB和BWP的取舍逻辑时间维度的框架搭好之后再看频域。5G的频域资源和LTE最大的不同是引入了资源栅格和BWP的概念同时因为SCS可变RB的带宽不再是固定180kHz一切都要按具体的SCS来换算。3.1 资源栅格里最重要的两个概念RE和RBNR的频域资源从底层往上分三层子载波频域的最小单位宽度就是SCSREResource Element一个时域符号 × 一个频域子载波围成的最小资源单元RBResource Block频域上12个连续子载波加上时域上一个时隙正常CP下14个符号构成一个基本的调度资源块。RB的带宽等于12 × SCS。在SCS15kHz时RB带宽180kHz跟LTE一样在SCS30kHz时RB带宽360kHzSCS120kHz时RB带宽1.44MHz。这一点在射频和基带联调时特别容易出问题——如果一个终端上报的CQI对应的RB数量是按30kHz算的而网络侧按15kHz理解调度的数据量就会差一倍吞吐率统计也会对不上。NR的频域资源栅格还有一个特别的“参考点A”Point A所有RB资源块的编号都从点A开始点A的位置通过高层信令下发。点A的引入让不同带宽段的资源定义有了统一的锚点也为后续BWP切换提供了基准。3.2 BWP终端能力与载波带宽之间的“变速器”BWPBandwidth Part带宽部分是NR相对LTE最重要的结构性创新之一。你可以把BWP理解成一条宽阔的马路上划分的可变车道一个NR载波哪怕配置了100MHz的带宽终端不一定必须一直看守和占用全部100MHz而是只激活其中一部分带宽来收发数据。每个小区可以给UE配置最多4个下行BWP和4个上行BWP但同一时刻只有1个下行BWP和1个上行BWP处于激活状态。BWP的设计至少带来三个实际好处终端功耗下降大部分时间UE只在一个较窄的BWP内做PDCCH监听和数据收发射频前端不需要全程打开超宽带接收链路。实测中激活窄BWP相比全带宽接收终端的接收功耗能下降20%到30%这是5G手机续航优化的关键手段之一终端能力折中不同价格档位的手机支持的射频带宽能力不同。有些千元机最大只能收60MHz带宽网络侧就给它配一个60MHz以内的BWP它照样能在100MHz载波里正常接入干扰协调和灵活调度不同业务的BWP可以差异化配置比如eMBB用大BWP保证速率URLLC用小BWP降低盲检复杂度互不干扰。这里要提醒一个常见误区初始BWP很重要。UE刚接入小区时在还不知道小区完整配置之前只能通过MIB里的信息来确定初始BWP的位置和大小SSB、RMSI和RACH都在这个初始BWP里传输。初始BWP如果配得太宽覆盖受限配得太窄又可能塞不下必要的系统消息。实际配置里中频段初始BWP一般配20MHz到40MHz要兼顾接入成功率和覆盖。BWP切换是靠DCI里的带宽部分指示字段触发的而且切换通常伴随几十微秒到几毫秒的激活延迟。如果BWP切换过于频繁反而会出现“切来切去、数据停顿”的体验问题。优化时最好通过小区级参数设置BWP的驻留定时器避免用户在一个信噪比波动的环境里被反复切换。3.3 载波聚合和补充上行频域结构的两种扩充玩法在单载波资源之外NR传输结构还有两个重要的频域扩展机制载波聚合CACarrier Aggregation把多个成员载波合成一个大的传输带宽单用户吞吐可以成倍提升。NR的CA最多支持16个成员载波但在Sub-6GHz实际组网中常见的是2载波或3载波聚合比如3.5GHz频段两个100MHz载波聚合再加上2.1GHz的FDD载波。CA场景下每个成员载波都有自己的BWP配置主小区和辅小区的调度可以分别进行跨载波调度由PDCCH完成。CA最大的坑在于辅小区激活管理的时延激活太慢聚合增益体现不出来激活太快终端耗电增加一般建议结合业务量门限做辅小区去激活。补充上行SULSupplementary Uplink则很巧妙地解决了TDD中频上行覆盖受限的难题。典型配置是下行用3.5GHz大带宽保证速率上行在覆盖边缘从3.5GHz切到1.8GHz或700MHz/900MHz的低频段发送。SUL不增加下行容量但对提升“远离基站的上行体验”效果显著。做广覆盖优化时SUL的功率控制参数、SUL和NUL之间的切换门限都要精细调整如果切得太激进用户明明在低频SUL上发射良好却因为网络侧保守的评估策略迟迟不切换上行体验一样上不去。4. 传输结构的骨架物理信道与参考信号的映射规则时域和频域的资源框架搭好下一步就是搞清楚这些资源上到底“跑什么车”——也就是各种物理信道和参考信号是怎么被放到传输结构里去的。4.1 下行物理信道SSB、PDCCH、PDSCH各负责什么下行方向有四个核心信道SSB同步信号和广播信道由PSS、SSS和PBCH组成在时域上占4个符号频域上占240个子载波20个RB。SSB是UE接入小区的“第一眼”PSS/SSS帮助UE完成时间和频率同步并拿到小区IDPBCH承载MIB。PDCCH物理下行控制信道承载DCI下行控制信息负责告诉UE“下一步调度谁、怎么调度”。PDCCH在CORESET控制资源集里传输每个时隙的控制区域是单独配置的PDSCH物理下行共享信道真正的用户下行数据通道承载RRC信令和用户业务数据PCFICH和PHICH在NR中没有了对应的功能被整合进PDCCH。NR的控制信道设计明显简化了LTE里“每子帧都要发固定控制信息”的结构改为按需配置资源利用率更高。SSB的传输有一个非常关键的“波束扫描”机制。大规模天线阵列下NR通过时分复用把SSB在不同波束方向上轮流发送。时域上的SSB集合被组织成SS Burst Set在一个突发周期内完成一轮扫描。这意味着UE的初始接入实际上是“撞”上了某个方向的波束才完成的。在优化覆盖时SSB的波束数和周期必须跟实际覆盖场景匹配密集城区要多波束扫描保证每个用户方向都能收到较优的信号郊区可以适当减少波束数压缩开销。4.2 上行物理信道PUCCH、PUSCH、PRACH的分工上行方向的信道分工非常明确PRACH物理随机接入信道UE发起随机接入时使用承载preamble。PRACH在时域上占1到2个符号长序列preamble格式可占更多频域上按配置占6个或12个RB。随机接入是UE从空闲态走向连接态的第一脚油门PRACH的资源和功率参数配置直接影响接入成功率PUCCH物理上行控制信道主要承载HARQ反馈确认/否定确认、SR调度请求和CSI信道状态信息上报。PUCCH一般位于上行BWP的两端这种设计是为了实现频域选择性增益同时避免和PUSCH的调度冲突PUSCH物理上行共享信道用户上行业务数据的“主车道”动态调度或免调度模式都可以承载。做上行优化时记住一句经验“先看PUCCH再看PUSCH”。很多用户反馈上行时延大、重传多不一定是数据信道PUSCH的问题而是PUCCH的HARQ反馈没有及时到达基站收不到反馈自然判断调度失败了。PUCCH的功率控制参数、格式选择、资源分配在现网里经常需要按覆盖场景微调尤其是远点用户的PUCCH可靠性是上行体验的隐形瓶颈。4.3 参考信号不是“噪音”是系统的“眼睛”NR里参考信号的种类和用途比LTE丰富不少参考信号主要用途关键特点DMRS解调参考信号PDSCH/PUSCH/PDCCH解调时的信道估计仅存在调度的资源块内带宽跟随数据CSI-RS信道状态信息参考信号信道质量测量、波束管理、精细CSI上报可配置多种周期和密度用于下行测量SRS探测参考信号上行信道估计和下行波束选择辅助可做宽带探测辅助高频波束管理PTRS相位跟踪参考信号补偿相位噪声尤其在毫米波频段配合DMRS使用密度与调制阶数相关TRS跟踪参考信号时间和频率精细跟踪一般随SSB周期配套配置很多人分不清DMRS和CSI-RS简单记DMRS是“干活用的”CSI-RS是“评估用的”。解调像开车时的路况实拍必须有车经过的地方才有图像对应DMRS只在数据调度的RB里出现而CSI-RS像定期巡逻的监控探头周期性扫视全网的信道质量网络据此决定调度策略。在毫米波高频场景PTRS的设计值得单独说一句。高频段的相位噪声会让信号星座图“旋转发散”PTRS就是一颗定盘星让接收机估计并补偿相位误差。如果高频小区里用户吞吐突然跳水排查手段之一就是看PTRS的密度配置是否跟调制阶数匹配。5. 一次完整的数据传输是怎么在NR结构上跑起来的前面几节把NR传输结构的各个零件都拆开了最后一步是把它装回整机里看一次真实的传输流程。从UE开机到业务数据在空中跑起来整个过程其实就是传输结构被逐步调用的过程。5.1 小区搜索和随机接入传输结构的“第一次握手”UE刚开机时对网络一无所知唯一的线索是它支持的工作频段。第一步是盲检SSBUE在可能的工作频段上粗糙扫描通过检测PSS/SSS完成初始同步并根据PBCH里的MIB获取初始BWP的位置、SCS配置等关键参数。拿到MIB之后UE继续在初始BWP里读取SIB1RMSISIB1承载小区接入的“详细说明书”TDD框配比、PRACH配置、公共信道功率等。这个阶段全部发生在初始BWP内其中SIB1的调度信息由PDCCH上的SI-RNTI加扰DCI指示UE用SIB1里的小区接入参数完成随机接入。随机接入流程本身也是严格按照传输结构完成的UE在PRACH的时频资源位置发送preamble基站在PDSCH上用随机接入响应窗口回复RAR然后UE在PUSCH上发送Msg3RRC Setup请求基站再发Msg4完成竞争解决。这一来一回四次消息涉及到的信道和资源就是传输结构在接入期的全部核心节点。实际网络里有一个非常典型的接入失败场景同一个区域里SSB的波束方向和PRACH资源没有对齐。UE明明能收到高质量的SSB信号但PRACH的preamble发送时刻或频域位置配置在覆盖盲区接入还是失败。这也是为什么很多网优平台会把“SSB波束级别覆盖”和“PRACH前导接收分布”放在一起看。5.2 调度传输从DCI到PDSCH/PUSCH的一整套流程连接态下一次下行数据发送的典型流程是基站PDCCH上发送DCIDCI里包含PDSCH的时频位置、调制编码方式、HARQ进程号、天线端口等关键调度信息UE盲检PDCCH解析出DCI后按DCI指示在对应的PDSCH时频资源上解调数据UE根据PDSCH的CRC校验结果生成HARQ反馈在PUCCH上把ACK/NACK送回基站基站根据反馈决定是重传还是发送新数据。上行数据发送的流程类似只是角色的位置换了基站通过DCI 0_0/0_1调度PUSCHUE按指示在对应时频资源上发送数据并向基站反馈SRS或CSI帮助基站维持信道信息。整个流程中时隙级别的“数据—控制—反馈”的循环就是通信系统的节拍器哪一个环节的时频资源错位都会直接影响吞吐和时延。在优化过程中分析用户速率上不去第一件事就是确认“限速出现在下行还是上行”然后查对应方向的调度RB数、MCS分布和HARQ重传率。这三个指标的异常根源90%都能落到传输结构上RB上不去是频域资源的调度窗口没打开MCS偏低是信道估计或波束管理的问题重传率高则是DMRS密度、PUCCH配置或干扰底噪的锅。5.3 多天线和波束在传输结构上的叠加效应NR的大规模天线技术Massive MIMO和波束管理跟传输结构是深度耦合的不能把两者割裂开理解。高频段尤甚。在毫米波场景基站的每个发射方向就是一套“波束”SSB、CSI-RS、PDCCH、PDSCH都可以打在各自对应的波束上。传输结构里每个时隙、每个RB其实都隐含着一个波束维度的信息。波束管理分三个阶段初始波束扫描基于SSB、波束细化基于CSI-RS、波束失败恢复BFD和BFR。波束失败恢复在时域上发生在MAC层流程本身也消耗特定的PRACH机会和PUCCH资源。所以我们做传输优化的思路必须从“小区级平均”升级到“波束级精准”。比如一个高楼覆盖场景下行覆盖没问题的结论不够用你得细化到“哪个波束覆盖的哪个楼层有问题”再去看这个波束对应的SSB索引在时隙里分配的位置、CSI-RS的测量周期是否太稀疏。传输结构决定了射频信号在时间和频率上的摆放方式波束管理则决定了能量在空间上的指向两者配合起来NR的性能才能榨干。至于无线上面的各种调优经验我个人的体会是千万别试图绕过基础去理解优化动作。市面上你会看到很多像是“调高某某参数到XX解决了千兆体验”的秘诀贴但如果你能把NR传输结构吃透这些参数在你眼里就不是一串神秘数字而是时域的某个符号位置、频域的某段RB资源、控制信道里的某个DCI域。参数可以背结构必须懂。这篇文章把这套结构从头到尾串了一遍真正把它消化掉后面再遇到吞吐率上不去、时延异常、接入失败这些问题你起码知道往传输结构的哪个位置去怀疑。
阅读完成 · 觉得有帮助？
