1. 项目概述为什么先讲总体架构与物理层做5G NR协议栈开发或者测试的同行应该都有体会很多人一上来就扎进RRC信令、NAS流程里结果遇到物理层相关的问题就抓瞎。比如邻区添加失败、切换异常、随机接入反复失败兜兜转转排查半天最后发现根因在物理层——SSB频点配错了或者PUSCH功率没算对。这个系列文章我打算从总体架构开始逐步往下拆协议栈的每一层第一期先把框架和物理层讲透。这篇内容覆盖三块第一5G NR协议栈的整体分层结构包括控制面和用户面各有哪些层、层间怎么交互第二物理层在整个协议栈里的位置和它承担的核心职责第三物理层最关键的功能模块——小区搜索、SSB解析、上下行信道、参数集、波束管理以及这些模块在实际工程里怎么配合。适合三类人看刚转5G的协议栈开发工程师、做基站或终端物理层测试的同行、以及想从信令往物理层深入理解空口行为的网优工程师。先说一个基本判断5G NR和4G LTE的物理层差异比大多数人想象的大得多。LTE物理层基本是固定参数集——15kHz子载波间隔、固定帧结构而NR引入了灵活参数集子载波间隔可以是15/30/60/120/240kHz可配。这一改动直接影响了后续所有物理层功能的实现逻辑从时频资源映射到波束管理再到调度时序全部围绕这个核心变化重新设计。理解不了参数集就理解不了NR物理层的半边天。2. 5G NR协议栈总体架构拆解2.1 控制面与用户面的分层设计5G NR协议栈继承了LTE的分层思想但针对5G的业务场景做了大量调整。整体上分为控制面C-Plane和用户面U-Plane两条栈。控制面负责信令的生成、传输和解析包括RRC连接管理、移动性管理、安全激活等用户面负责实际业务数据的传输核心是IP数据包的封装、调度和空口发送。从协议栈各层的归属看从上到下分别是NAS层非接入层终端和核心网之间的信令主要处理注册、鉴权、会话管理。对空口协议栈来说NAS层是透明传输的RRC把它当作透传数据块封装进消息里。RRC层无线资源控制控制面的核心大脑负责系统消息调度、连接管理、测量配置、切换控制。NR的RRC引入了大量的灵活配置能力比如BWP配置、波束配置、CA/DC配置都集中在RRC消息里下发。PDCP层分组数据汇聚协议头压缩、加密、完整性保护。5G NR对PDCP的要求比LTE更高因为要支持双连接场景下的数据分流和重排序。RLC层无线链路控制分段、重传、按序递交。NR的RLC有三种模式——TM透明模式、UM非确认模式、AM确认模式实际组网中最常用的是AM模式。MAC层媒体接入控制调度、优先级处理、HARQ重传、逻辑信道复用。MAC层是物理层和上层之间的中转站调度器就住在MAC层。PHY层物理层把MAC层下来的传输块做编码、调制、资源映射最终通过天线发射出去。用户面和控制面在PDCP层以下基本复用同一套协议栈区别在PDCP之上的承载类型。控制面的SRB信令无线承载走RRC用户面的DRB数据无线承载直接对接SDAP层SDAP负责QoS流到DRB的映射这是5G新增的一层主要服务于核心网的QoS流模型。2.2 NR协议栈相比LTE的关键变化NR协议栈不是LTE的小修小补有几个结构性变化必须在理解总体架构时建立起来。第一个变化是RLC分段的职责重新分配。LTE里RLC负责分段MAC负责复用NR里MAC层也能做分段这叫“逻辑信道优先级处理时的MAC分段”。这个改动看似不起眼实际影响不小——动态调度时MAC可以根据当前可用的物理资源量精确控制从每个逻辑信道取多少数据低时延业务不用等RLC层的重分段调度粒度细了很多。第二个变化是PDCP层引入了重排序功能。LTE的PDCP只做头压缩和加密按序递交是RLC的活。NR因为要支持多路径双连接、CA下的跨小区调度RLC的数据可能从不同路径到达终端顺序会乱所以把重排序上移到PDCP统一管理。这也是为什么NR的PDCP缓冲区和定时器参数和LTE差异很大——它要管的不只是单个链路的重传还有多链路间的排序。第三个变化是把波束管理直接做进了协议栈。LTE没有波束的概念天线发出去是全向或扇区级的覆盖。NR高低频段并用高频段路径损耗大单靠全向发射覆盖能力太差必须用波束成形把能量集中在特定方向。这就导致物理层新增了波束测量、波束上报、波束失败恢复这套机制RRC、MAC、PHY三个层都得配合处理波束这在LTE协议栈里完全没有对应物。2.3 逻辑信道、传输信道与物理信道映射关系理解协议栈不能只看层还要看“信道”这个概念。数据从上往下走依次经过逻辑信道、传输信道、物理信道这三层映射每一层都有自己的“打包方式”。逻辑信道定义的是“传什么内容”——控制信令还是业务数据。常见的有PCCH寻呼、CCCH公共控制、DCCH专用控制、DTCH专用业务等。MAC层把逻辑信道的数据按优先级和QoS要求复用到传输信道上。传输信道定义的是“怎么传”——数据在空中接口上以什么方式传输。NR的传输信道比LTE少去掉了BCH广播信道广播内容移到物理层直接承载只保留了DL-SCH下行共享信道、UL-SCH上行共享信道、RACH随机接入信道、PCH寻呼信道。5G的广播消息MIB直接在物理层的PBCH上发送不再经过传输信道的适配。物理信道定义的是“用什么资源传”——具体的时频资源、调制方式、天线端口。NR下行物理信道主要有PBCH承载MIB和PSS/SSS一起组成SSB块PDCCH承载DCI调度信令相当于物理层的“命令通道”PDSCH承载实际的下行业务数据和部分信令相当于“数据通道”上行物理信道主要有PRACH随机接入信道终端第一次发起上行传输用的PUCCH承载UCI上行控制信息包括HARQ反馈、CQI/PMI/RI等PUSCH承载上行业务数据和上行控制信息复用传输物理信号则分为上行参考信号DMRS、SRS、PTRS和下行参考信号PSS/SSS、DMRS、CSI-RS、PTRS。这些信号不承载业务内容但负责解调参考、信道测量、同步、波束管理等关键功能。3. 5G NR物理层核心功能深入解析3.1 参数集Numerology整个NR物理层的地基参数集是NR物理层最基础、也最能体现设计思路的概念。LTE用固定的15kHz子载波间隔好处是简单坏处是灵活性差——低频段追求大覆盖15kHz没问题但高频段要对抗大频偏和相位噪声需要更大的子载波间隔来缩短符号时间固定参数就吃不消了。NR把子载波间隔定义为[ \Delta f 15 \times 2^{\mu} \quad \text{kHz} ]其中μ取0到4对应15/30/60/120/240kHz。μ的每个取值对应一套完整的时域结构——循环前缀长度、每时隙OFDM符号数、每无线帧的时隙数都不一样。常用的是μ130kHz和μ3120kHz前者用于中低频段的广覆盖后者用于高频段的宽带传输。参数集为什么重要因为它决定了时频资源的最小粒度。NR的资源网格以“资源块RB”为单位一个RB频域占12个子载波时域占一个时隙。子载波间隔变大单个OFDM符号的时间变短同样的时隙时长内能塞更多符号但符号变短意味着保护间隔变短抗多径能力下降。所以选参数集本质上是在“时延、覆盖、抗干扰、峰值速率”之间做权衡。实际工程里一个小区可以同时配置多个BWP带宽部分每个BWP可以有不同的参数集。比如FR1频段450MHz-6GHz常用30kHz做初始BWP再配置一个15kHz的BWP给某些对覆盖更敏感的UE。终端通过RRC重配消息在BWP之间切换这比LTE的整个载波带宽一把抓灵活太多。3.2 帧结构、时隙配置与HARQ时序NR的帧长度固定10ms一帧分成10个子帧每子帧1ms。每个子帧包含的时隙数由参数集决定——μ0时一子帧1个时隙μ1时一子帧2个时隙μ2时一子帧4个时隙。公式是[ \text{每子帧时隙数} 2^{\mu} ]在30kHz子载波间隔下一个10ms帧内共有20个时隙每个时隙0.5ms包含14个OFDM符号常规CP时。NR一个大的变化是灵活的上下行时隙配比。LTE的TDD配比是固定的7种模式NR引入了“DL-UL-TransmissionPeriodicity”和slot格式组合配置可以按需把时隙配成纯下行、纯上行或混合时隙。5G的时隙格式由一个叫“SlotFormat”的表控制RRC配置动态DCI指示相结合理论上可以做到每几个时隙就重新配置一次上下行比例。这带来的一个连锁影响是物理层时序的变化。LTE的HARQ时序基本固定——下行数据后4ms反馈ACK/NACK上行传输前4ms收到调度命令。NR因为参数集和上下行时隙配比可变HARQ时序变成了配置项。下行HARQ反馈通过PUCCH发送具体在哪个时隙反馈由“PDSCH-to-HARQ-feedback timing indicator”字段控制可以是同一个时隙、隔几个时隙甚至跨子帧。上行调度的K2值PDCCH到PUSCH的间隔也是RRC里配好的候选值DCI动态选择。这个设计对理解5G空口时延很重要。如果你在排查“为什么这个UE的HARQ反馈那么慢”不要直接怀疑设备出了问题先查一下时隙配置和时序参数是不是合理。很多低时延业务的时延瓶颈不在空口速率而在HARQ往返时间被时隙结构拉长了。3.3 SSB与小区搜索终端开机后干的第一件事终端开机后没有任何先验信息它要做的事是“找小区”。这个过程的物理层实现是围绕SSBSS/PBCH Block展开的。SSB是PSS主同步信号、SSS辅同步信号、PBCH、PBCH的DMRS四样东西打包在一起的时间-频率资源块时域占4个OFDM符号频域占20个RB240个子载波。PSS/SSS是已知序列终端不知道小区ID的情况下通过相关检测就能识别出来PBCH承载MIB包括系统帧号、子载波间隔、SSB子载波偏移、PDCCH配置信息等这些是终端读取后续SIB1必需的信息。SSB在时域上的发送位置不是固定的。NR把SSB在时隙内的几种可能位置定义成“Case A到Case E”具体用哪个取决于频段和子载波间隔。比如30kHz时隙下Case B定义SSB的起始符号为{4,8,16,20}一个时隙内可能发送多个SSB。这些SSB在频域上也可能分布在不同的RB位置终端需要盲检。盲检的实际过程是这样的终端先假设一个子载波间隔和频段在中心频点附近搜PSS。搜到PSS后得到粗略的时频同步和小区ID的前一半信息再用SSS确认完整的PCI。然后解调PBCH的DMRS根据DMRS的位置和序列确认SSB的索引接下来解调PBCH拿到MIB。整个过程在终端侧要求极低信噪比下也能工作——PSS/SSS序列相关增益高PBCH用极化码编码纠错能力强。实测下行同步在这个过程通常在几十毫秒内完成但如果SSB频点配置和终端盲检范围不匹配终端会一直在那转圈找不到小区。还有个关键概念叫SCS同步栅格。NR的SSB频域位置不是随便放的规范定义了同步栅格上的GSCN全局同步信道号基站只能把SSB放在GSCN对应的频点上。终端盲检时也是按GSCN逐个搜索。这就是为什么很多“小区搜不到”的问题——基站侧SSB频点设置不在标准GSCN栅格上或者和终端能力支持的频点范围不匹配。3.4 物理下行控制信道PDCCH与DCIPDCCH是所有下行调度的“司令塔”。终端在哪个时隙的哪些资源上收PDSCH数据、用什么MCS调制编码、HARQ进程号是几全部由PDCCH上携带的DCI下行控制信息决定。PDCCH在频域上占用CORESET控制资源集配置的RB集合时域上占用1到3个OFDM符号。终端需要盲检CORESET内的候选PDCCH用RNTI无线网络临时标识去解扰DCI的CRC匹配上了才说明这条DCI是发给自己的。主要有几类RNTIC-RNTI单用户调度每个连接态UE独有RA-RNTI随机接入响应使用P-RNTI寻呼SI-RNTI系统消息调度TC-RNTI随机接入过程中的临时标识盲检次数是有上限的——终端能力决定了一个时隙内最多盲检多少次PDCCH候选和多少个DCI。实际运维中如果在系统里看到“PDCCH盲检漏检率偏高”先看是不是CORESET配置的聚合等级分布不合理导致终端在有限盲检次数内没覆盖到实际使用的聚合等级再看是不是干扰导致信噪比差、解调失败率高。DCI的格式分好几类DCI format 1_0和1_1用于下行调度0_0和0_1用于上行调度2_0到2_4用于时隙格式通知、PDCCH抢占指示等特殊场景。1_1和0_1是常规调度使用的字段很多包括频域资源分配、时域资源分配、MCS、HARQ信息、天线端口、SRS请求等等。做物理层测试时DCI内容的解析准确率是检验实现正确性的核心指标之一。3.5 物理上行共享信道PUSCH与功率控制PUSCH承载用户上行数据同时也能复用传输上行控制信息。PUSCH的调度有两种方式——动态调度和配置授权Configured Grant。动态调度走PDCCH上的DCI 0_0/0_1每次传输都要一个调度命令配置授权则是一次性配置好周期性传输资源UE按周期直接发数据。后者是URLLC低时延场景的关键技术——终端不用等调度省去了调度请求和授权一来一回的时间。PUSCH的功率控制是物理层一个容易出问题的环节。NR的上行功率控制公式比LTE复杂涉及开环功率、路损补偿、闭环功率调整、MCS相关的功率偏置等多个分量[ P_{\text{PUSCH}} \min\left{P_{\text{CMAX}},\ 10\log_{10}(M) P_{\text{O_PUSCH}} \alpha \cdot PL \Delta_{\text{TF}} f(i)\right} ]其中M是分配的RB数P_O_PUSCH是目标接收功率α是路损补偿系数0到1之间取PL是终端估计的下行路损Δ_TF是传输格式相关的偏置f(i)是闭环功率调整量。调试时最常遇到的问题就是路损估计不准——如果基站侧给终端的参考信号功率配置不对终端算出来的PL偏大发出来的功率过高造成干扰偏小则解调失败终端反复升高功率形成干扰的恶性循环。做测试时我见过不少“UE在小区边缘怎么都上不了行”的案例排查到最后发现是P0_PUSCH和α配得不合理——α取大一点让终端在边缘时功率补偿更激进或者把P0调高一点提升整体目标功率问题就解决了。3.6 参考信号DMRS、CSI-RS、SRS的角色分工参考信号是物理层最容易被轻视的模块。很多人觉得参考信号就是“导频”随便配配就行。实际上NR的三种主要参考信号各有分工配置错了直接影响性能。DMRS解调参考信号和解调数据绑定在一起作用是让接收机估计信道冲激响应。下行PDSCH的DMRS配置有type1和type2两种映射方式type1一个RE上放6个端口type2放12个根据MIMO层数选择。DMRS分前置DMRS和附加DMRS前置DMRS放在数据开始的位置让接收机尽快开始解调附加DMRS放在时隙后面的符号上用于高速移动场景的信道跟踪。高铁、高速等高速场景如果没有配足够多的附加DMRS解调性能会急剧恶化。CSI-RS信道状态信息参考信号用于信道测量。终端基于CSI-RS做信道估计算出CQI信道质量指示、PMI预编码矩阵指示、RI秩指示通过PUCCH/PUSCH上报给基站基站再据此确定调度策略。CSI-RS还承担波束管理的测量功能——多个CSI-RS资源对应不同的波束方向终端测量后上报参考信号接收功率基站选出最优波束。做波束管理测试时CSI-RS资源的数量、时频位置、周期都要精心设计资源之间不能冲突。SRS探测参考信号上行信道测量的工具。终端发SRS基站侧接收后反推上行信道状态用于上行调度和波束选择。SRS和DMRS的一个重要区别是SRS可以宽带发送覆盖整个BWP做全带信道探测帮助基站做频选调度而DMRS只存在于实际调度的资源块上。SRS还支持天线切换——终端有多根天线但只有一个发射通道时通过SRS天线切换可以让基站分别估计所有天线对应的信道。个人经验排查“下行速率差”问题时先看CSI-RS配置是否合理再看终端上报的CQI是否和现场覆盖情况匹配排查“上行速率差”问题时先看SRS发送周期和带宽是否足够再看基站侧上行DMRS解调是否稳定。这两套检查做完大多数物理层性能问题都能定位到方向。4. 5G NR物理层核心流程实操解析4.1 从开机到驻留物理层完整流程串联把物理层的各个功能模块串联起来看一遍才能体会到它们之间是怎么协同的。下面以终端从开机到完成初始接入的全过程为例梳理物理层每一步做了什么。步骤1频点扫描和PSS检测。终端根据自身频段能力和设置的搜索范围逐个GSCN频点做能量检测。发现候选频点后尝试在该频点附近检测PSS。PSS相关峰值超过阈值就认为找到了潜在小区。步骤2SSS检测和PCI确认。利用PSS的时频同步结果在同一SSB时隙里检测SSS得到完整的物理小区IDPCI 3×N_ID1 N_ID2。步骤3PBCH DMRS和PBCH解调。在SSB的第三个OFDM符号上解调DMRS确定SSB索引进而解调PBCH拿到MIB。MIB里有系统帧号高6位、子载波间隔、SSB子载波偏移k_SSB、PDCCH SIB1配置信息等。步骤4CORESET0和SIB1获取。根据MIB里的PDCCH配置终端在对应的CORESET0初始控制资源集上盲检PDCCH查找调度SIB1的DCI。收到DCI后解调PDSCH拿到SIB1。SIB1包含小区接入参数、上下行载波带宽、PRACH配置等终端有了这些信息才能发起随机接入。步骤5PRACH前导码发送。SIB1里有PRACH资源的时频位置和前导序列格式。终端随机选择前导码在配置的PRACH时机上发送。基站收到后检测前导码得到RA-RNTI和前导码标识并通过随机接入响应RAR回复携带临时C-RNTI、时间提前量、上行授权。步骤6MSG3发送和竞争解决。终端收到RAR后在上行授权上发MSG3RRC连接请求。基站通过竞争解决消息确认哪个终端接入成功同时把临时C-RNTI升级为正式C-RNTI。初始接入物理层流程到此完成。整个流程里任何一个环节失败都会导致接入失败。区别在于失败的表现方式不同——PSS/SSS没检测到终端会一直驻留在“找小区”阶段不会有任何上行信号PRACH发了但基站没响应终端会重试并升高前导功率MSG3发了没收到竞争解决消息终端重新发起随机接入。通过信令跟踪工具看这些失败发生在哪个节点就能快速反推物理层哪个模块出了问题。4.2 SSB频点规划与GSCN计算实例SSB频点规划是物理层实际落地的第一步也是最容易出错的一步。NR的SSB位置由GSCN定义不能随意设置。我以一个实际场景说明计算过程。假设现网使用n78频段3300MHz-3800MHz计划将SSB放置在3500MHz附近。根据GSCN的计算规则n78属于0到3000GHz范围的频段GSCN计算公式为[ \text{GSCN} 6001 \frac{F_{\text{SSB}} - 3000\text{MHz}}{5\text{kHz}} ]如果选F_SSB 3500MHz那么[ \text{GSCN} 6001 \frac{3500 - 3000}{0.005} 6001 100000 106001 ]这个计算结果要转成实际配置里的ARFCNNR绝对射频信道号中间还涉及SSB子载波间隔、offsetToPointA等因素。实际配置时我习惯先用软件工具如NR规划工具或现网配置查询工具把GSCN算出来再反查SSB落点是否在该频段的同步栅格范围内。很多现场问题是因为工程师图省事把SSB随意放在一个非GSCN的频点上导致终端扫不到。还要注意SSB和BWP的关系。初始BWP必须包含SSB的频域位置否则终端在初始接入阶段读不到系统消息。常见错误是SSB频点设了但初始BWP的起始RB和RB数没有覆盖到SSB导致终端能检测到SSB但解不到SIB1——这个问题的排查要同时看SSB频点和BWP配置是否对齐。4.3 波束管理与波束失败恢复实操波束管理是NR物理层区别于LTE的典型功能尤其在FR2毫米波频段波束管理直接决定了连接能否建立和保持。波束管理分几个阶段初始波束建立基站通过发送同步信号块在不同方向上的波束扫描终端测量发现最强波束上报波束索引。波束调整基站通过配置CSI-RS资源并让终端测量上报波束参考信号接收功率持续跟踪波束变化。波束失败检测与恢复当终端检测到当前波束质量恶化比如波束参考信号接收功率低于阈值触发波束失败恢复流程——终端在专用的PRACH资源上发送波束失败恢复请求基站通过专用PDCCH响应新的波束配置。实际组网中波束失败恢复是高频段掉线问题的主要原因之一。排查这类问题重点看三个配置第一波束失败检测的参考信号配置是否合理。如果检测参考信号周期太长比如80ms以上终端发现波束失败的时间延迟太大恢复也会慢。第二候选波束列表是否覆盖了所有可能的切换方向。很多掉线是因为候选波束列表配置不全最优波束退化后终端找不到备用波束。第三波束失败恢复的PRACH资源是否和普通随机接入资源有冲突。如果冲突恢复请求会被普通接入请求淹没基站检测成功率下降。低频段FR1虽然波束宽度大但也有波束管理和波束失败恢复的应用场景——大规模天线的波束成形不仅用在高频段在FDD中低频段的容量提升项目里也很常见。所以别觉得波束管理是毫米波独占的技术5G-A时代的低频段也会更依赖它。5. 5G NR物理层常见问题与排查技巧实录5.1 小区搜索失败从频点到配置的四步排查法我参与过的项目中“终端搜不到小区”是最常被拉去救火的物理层问题。这种问题排查有个固定的套路按顺序做四步检查基本能覆盖90%以上的原因。第一步检查SSB频点是否在标准GSCN栅格上。用终端log的盲检过程看不出来直接用路测软件或频谱仪看对应频点有没有SSB信号。没有信号先查基站侧SSB配置和射频通道是否正常。有信号但终端搜不到大概率是频点不在终端支持的搜索范围内。第二步检查PSS/SSS的功率配置。如果SSB功率设太低终端在远点或者遮挡严重的场景下检测不到。SSB功率一般要单独配置不要把下行业务参考信号功率直接当成SSB功率。有的基站设备默认把两者设成一样的实际组网时建议SSB功率略高于业务信道保证小区边缘和初始接入的覆盖。第三步检查终端侧频段能力。不同终端支持的频段范围不一样特别是某些定制终端或旧款终端n78频段范围可能只支持部分子集。SSB频点对不上终端的支持频段找得再多也没用。第四步检查外部干扰。用频谱仪扫SSB频点附近有没有强干扰信号。5G干扰排查里SSB所在频点如果和DAS系统、私装信号放大器等杂散信号有重叠很多弱场接入失败都是被这种外部干扰打掉的。5.2 随机接入失败的物理层根因定位随机接入失败分两类PRACH没发出去、PRACH发出去了但基站没检测到。PRACH没发出去先看终端是否完成了下行同步和系统消息读取。很多随机接入失败的根因不是随机接入本身而是之前的小区搜索或SIB1解码就没成功终端压根不知道PRACH资源在哪。通过终端log查看“PRACH目的”字段能区分是初始接入、切换接入还是波束失败恢复——三者用的PRACH资源不同失败原因也可能分别对应不同问题。PRACH发出去了但基站没检测到排查重点转向三个方面前导码格式配置是否合理、PRACH时机是否有干扰、上行同步是否准确。前导格式配置方面大覆盖半径的小区需要长前导序列比如format 0适合小站format 2适合远覆盖如果覆盖半径很大却用了短前导基站的检测窗口覆盖不到自然检测失败。干扰方面PRACH资源如果和邻居小区的PUSCH调度资源重叠互相干扰会导致检测性能下降。这类问题在log上很难直接看出来需要用频谱仪做时频域的底噪测量。上行同步方面如果终端的TA时间提前量估计不对PRACH到达基站的时间偏移超出循环前缀容忍范围检测也会失败——这种情况常见于高速移动场景多普勒频偏导致定时漂移。5.3 下行速率不达标的物理层排查清单下行速率问题是物理层优化的重头戏。建立一个完整的问题排查思维框架比记住每一个具体问题更管用。我自己的排查顺序是先看无线环境再看参数配置最后对照终端能力。无线环境部分下载速率首先要看CQI。CQI低比如低于8说明信道质量差速率上不去是正常的物理限制这时候要解决覆盖或干扰问题而不是调协议栈参数。CQI高但速率还是上不去才轮到参数配置排查。参数配置部分重点检查PDCCH聚合等级和MCS表选择。聚合等级选低了终端收不到调度命令调度机会空转MCS表选保守了最高只能到64QAM速率天花板被卡死。还有HARQ最大重传次数、CQI上报周期、CSI-RS密度这些每一个都有可能在特定场景下成为瓶颈。终端能力部分注意UE的DL Category支持的最大MIMO层数和最大调制阶数。有的终端标称支持5G实际下行只支持2层MIMO和64QAM那么理论峰值速率自然只有4层加256QAM方案的一半。排查时如果只看基站侧配置会觉得一切正常把终端能力一比对才发现能力和预期不匹配。5.4 上行功率异常的现场处理经验上行功率问题在现网中常见表象包括上行速率波动大、邻区上行干扰高、UE掉话前过度升功率。物理层层面我分享三个实际经验。第一个经验先查路损补偿基准。很多上行功率异常问题的根因是基站下发的参考信号功率配置和实际发射功率不一致。比如SSB或CSI-RS的参考信号功率设了30dBm实际射频口只有27dBm终端据此计算出的路损就低了3dB上行发射功率整体偏高3dB造成无谓干扰。基站侧功率校准是上行功率问题排查的第一步。第二个经验闭环功率调整的步长和范围要设置合理。NR的TPC命令可以调整累积功率但如果步长最大2dB或更大增益调整范围太宽遇到信道快速波动时终端功率会震荡反而导致解调质量恶化。把TPC步长调小一些让功率调整更平滑能有效减少上行调度的不稳定情况。第三个经验PUSCH的开环功控目标功率P0和全补偿/部分补偿的选择要配合。城区高干扰场景适合调低P0、降低补偿系数α让终端别总是满功率发射郊区弱覆盖场景则反过来P0调高一些、α取1保证远点终端能发够功率。这个参数的调优没有统一答案要结合现场路损分布和干扰水平来做。5.5 物理层测试与log分析要点做5G物理层测试和调试工具链的熟练程度直接决定工作效率。我整理几个自己常用的工具和操作习惯。信道模拟器方面Keysight Propsim、Spirent、Rohde Schwarz的设备都常用做多径衰落场景时注意时延扩展和多普勒频移参数的设置要和真实场景匹配。频谱仪方面测SSB信号时用零频宽模式看频谱包络检查频点位置和带宽是否和配置一致测干扰时用余辉模式或者长时间最大值保持能把间歇性干扰抓出来。终端log分析方面主流终端芯片厂商高通的QXDM、MTK的CatTool等都能输出物理层级别的log。重点看几个关键参数的变化趋势RSRP、RS-SINR、CQI、MCS、RB数、HARQ重传率、PDCCH盲检次数。这些参数组合起来基本能还原物理层的每一次调度过程判断问题是在覆盖、干扰、调度还是终端侧。基站侧log分析方面看CQI分布和调度结果和终端侧log做对比能发现是信道估计的偏差问题还是调度器的策略问题。我实测中最常见的对不上是PDSCH的DMRS端口配置和终端上报的RI不匹配——基站以为终端能收4层终端实际只能收2层速率自然减半。这种问题从指标上不容易看出来因为调度是“成功”的只是用的层数和能力不匹配。6. 其他高频咨询问题速查我把过去几年被问得比较多、但不算单独成篇的问题整理成一个速查表方便同行快速定位。问题可能原因排查方向终端搜不到小区SSB频点不在GSCN栅格/功率过低/终端频段不支持频谱仪确认SSB信号核对GSCN与终端能力检测到SSB但解不到MIBSSB和BWP频域未对齐/PBCH信噪比差核对初始BWP配置检查SSB所在区域干扰收到MIB但SIB1读取失败CORESET0配置异常/PDCCH盲检失败检查CORESET0频域资源和PDCCH聚合等级随机接入失败PRACH资源冲突/前导格式与覆盖不匹配检查PRACH配置确认TA估计和干扰情况下行速率低CQI差/MCS表受限/MIMO层数不足查覆盖干扰核对MCS表和终端能力上行速率低功率不足/SRS周期长/上行资源分配受限查路损补偿核对SRS配置和PUSCH调度HARQ重传率高信道估计不准/干扰突发/附加DMRS缺失检查DMRS配置和外部干扰确认移动速度切换后速率骤降目标小区波束未对齐/CSI-RS配置弱检查波束管理和CSI-RS测量配置波束失败掉线候选波束不全/检测周期长完善候选波束列表缩短波束故障检测周期PDCCH漏检率高聚合等级不匹配/CORESET容量不足调整聚合等级分布扩展CORESET资源这张表没办法覆盖所有场景但它代表了一个思路物理层问题十有八九能归到“配置不对、资源冲突、能力不匹配、干扰”这四类中的一个。按照这个框架排查比零散地东查西查效率高得多。7. 实操心得与后续系列预告写到这里第一期的主要内容基本覆盖完了。最后分享几个个人经验希望对刚开始做5G物理层的同行有帮助。第一个体会学好NR物理层先学会从协议里找“为什么”。3GPP协议38.211物理信道调制、38.212复用和编码、38.213物理层过程这三本规范是核心但别指望一上来就看懂。我的建议是先看38.331RRC里的物理层配置参数结构再回到物理层规范里找参数的取值范围和含义这样能快速建立“配置项-物理层行为”的映射关系。第二个体会工具只能帮你定位问题不能帮你理解问题。无论用终端log还是基站后台最后都要落到物理层的基本原理上——子载波间隔、时频资源、参考信号的序列行为、功率控制的计算链路。原理扎实了任何新问题都能快速归因原理不扎实手上工具再多也只是瞎试。第三个体会做物理层测试一定要会看波形和频谱。很多配置类问题在log上看起来模棱两可但频谱仪一扫、信号解调一比对问题立刻一目了然。我带了几个新人发现他们普遍不重视频谱仪的操作能力一到现场就只知道看软件log效率很低。建议每个做物理层的同行都把“会用频谱仪做基础信号分析”当作基本功来练。第四个体会别忽视参数集之外的时间同步细节。5G物理层很多“疑难杂症”最后查出来都是时间对齐的问题——TA没估算准、时隙边界偏移、符号定时偏差累积。NR支持多种参数集共存后时间同步的边界条件比LTE复杂排查时多留个心眼。第五个体会多积累“现场感觉”。比如一个小区覆盖距离大概多远、SSB功率应该配多少、P0和α大概在什么范围才能兼顾覆盖和干扰这些数值在书本上没有标准答案但是做多了心里会有谱。数值一报出来就知道高不高低不低排查效率完全不一样。这个系列后续安排第二期准备讲MAC层和调度器——逻辑信道优先级处理、HARQ重传管理、调度请求和BSR缓冲状态上报、DRX配置对调度的影响第三期讲RLC和PDCP——分段与重传机制、头压缩、双连接下的数据分流与重排序第四期讲RRC连接管理和移动性——包括测量配置、切换流程、条件切换、NR和LTE互操作时的RRC信令差异。每一期仍然保持同样的风格先讲透为什么再讲怎么做最后是现场经验。如果你在阅读过程中遇到具体问题或者有想让我优先写的内容方向欢迎随时反馈。我做这行的时间越长越觉得物理层这东西看似门槛高但只要你把基本原理踏踏实实搞明白再复杂的协议流程都能拆解成一步步可定位、可验证的环节。希望这个系列能帮你把这个“拆解”的能力建立起来。