1. 5G NR里DMRS到底是什么搞懂它才算入了物理层的门做5G协议栈或者物理层算法的人几乎每天都要和DMRS打交道。不管是刚入行的应届生还是从4G转过来的老工程师第一次看38.211的时候基本都会被DMRS的时频结构绕晕。但说实话DMRS是整个5G物理层里最值得吃透的参考信号之一因为它的设计直接决定了PDSCH和PUSCH能不能正常解调也决定了MU-MIMO、波束管理这些5G核心特性到底能跑到什么程度。DMRS的全称是Demodulation Reference Signal中文一般叫解调参考信号。它在物理层干的事情很纯粹给接收机提供一个已知的参考让接收机估计出无线信道对信号造成的幅度变化和相位旋转然后补偿掉这些影响把数据符号正确解出来。你可以把它理解成一把“标尺”发射端在数据里混入一段接收端预先知道的图案接收端拿这个图案去比对收到的信号反推出信道的“扭曲程度”再用这个结果去校正数据部分。4G LTE时代其实也有DMRS但当时大家更熟悉的可能是CRSCell-specific Reference Signal小区参考信号。到了5G NRCRS被彻底干掉了DMRS成了PDSCH、PUSCH、PDCCH、PBCH这些信道的标配。这个变化不是简单的“换了个名字”而是整个参考信号设计思路的转变。LTE的CRS是“小区级持续广播”的不管这个用户有没有数据要传CRS都会在固定的时频位置一直发虽然解调方便但开销大也限制了大规模天线系统的扩展性。NR的DMRS则是“用户级按需发送”的只在有数据传输的资源块上出现而且位置、密度、端口数都可以配置灵活性比CRS高了一个量级。所以你要理解5G的很多关键指标比如峰值速率、频谱效率、MU-MIMO配对能力都绕不开DMRS这个底层设计。这篇文章适合谁看如果你在做5G基站物理层开发、协议栈实现、终端射频调试、网络优化或者准备面试5G通信算法岗位那这篇文章能帮你把DMRS的原理和实际配置捋清楚。我会从时频结构、端口映射、参数配置、性能影响、常见问题这几个维度展开尽量把38.211里那些干巴巴的公式翻译成能直接用的经验。2. DMRS时频结构拆解前置和额外位置到底怎么配合2.1 时域位置为什么分前置DMRS和额外DMRS先看DMRS在时域上长什么样。NR的一个时隙slot在常规循环前缀下是14个OFDM符号DMRS在符号维度上的位置由两个东西决定一个是映射类型Mapping Type另一个是配置的前置位置TypeA-Position或额外位置Additional Position。前置DMRSFront-Loaded DMRS是设计里最核心的一点它被放在一个时隙的前部目的是让接收机能尽早完成信道估计然后马上开始解调数据不需要等整个时隙收完。这对降低解调时延非常重要尤其在URLLC这种对时延极其敏感的场景里前置DMRS是刚需。映射类型A的DMRS位置通常在符号2或符号3具体由dmrs-TypeA-Position参数决定值是2或3单位是符号索引也就是说这个时隙一开始没多久就能做信道估计了。映射类型B则更激进DMRS直接放在数据符号的第一个位置连控制符号后面都不等主要用于非时隙级调度或URLLC的低时延传输。额外DMRSAdditional DMRS是在前置DMRS之后追加的参考信号用于应对信道随时间快速变化的情况比如高速移动场景。当终端跑到时速350公里的高铁上多普勒频偏很大会让信道在一个时隙内快速变化如果只用前置DMRS去估计整个时隙的信道后半段数据的估计误差会明显变大这时候就需要在时隙中间再插入额外DMRS来跟踪信道变化。额外DMRS的个数在RRC层通过dmrs-AdditionalPosition参数配置范围从0到3。这个参数不是越大越好因为它会占用数据RE直接降低传输效率。一般低速场景配置0或1就够了高速场景才考虑加到2或3。具体要加多少还得结合前置DMRS所处位置一起看比如Type A位置在符号3时配置1个额外位置一般放在符号8附近如果是Type B配置1个额外位置就放在第6个符号左右。这些位置在38.211的表格里都有明确约定实现时对照表格查就行。2.2 频域映射梳状结构和CDM组的配合逻辑频域上DMRS的映射方式用到了梳状Comb结构加码分复用CDM的组合拳。NR的DMRS分为两种类型Type 1和Type 2它们最直观的区别就是梳齿数不同。Type 1采用2梳结构每个OFDM符号上每两个子载波中有一个承载DMRS也就是说DMRS在频域上隔一个RE出现一次密度是50%。Type 2采用4梳结构每4个子载波中有一个承载DMRS频域密度是25%。梳齿数越少DMRS在频域上的密度越高对频率选择性信道的估计能力就越强同时支持的端口数也受限制。Type 1在单个符号上能支持4个端口Type 2在单个符号上能支持6个端口。要支持更多端口就得在时域上扩展用两个DMRS符号做CDM扩展Type 1能扩展到8端口Type 2能扩展到12端口。CDM组的设计是另一个关键点。你把梳状结构想象成把子载波分成了几组“车道”每个CDM组占据一个固定的梳齿位置然后组内再用正交扩频码OCCOrthogonal Cover Code来区分不同端口。Type 1有两个CDM组每组长度2的OCC区分2个端口Type 2有三个CDM组每组同样是长度2的OCC区分2个端口。这种设计的好处是不同端口在同一资源块上可以完全正交不会互相干扰这就给MU-MIMO的多用户配对创造了条件两个用户在相同的时频资源上传输用不同的DMRS端口接收机就能把它们区分开。这里有一个容易踩坑的地方CDM组之间是频分复用的组内的OCC是码分复用的但是当信道在频域上变化很快时OCC的正交性会遭到破坏。比如在高选择性信道下同一个CDM组内两个端口的信道响应差异很大OCC展开后会产生码间泄漏导致端口之间互相干扰。解决思路通常是让终端使用Type 2和更多的CDM组或者避免在强频率选择性信道上让同一CDM组内做高秩MU配对。2.3 端口到天线端口映射别被端口号吓住DMRS的端口概念和天线端口不完全是一回事。3GPP定义的天线端口是从“信道大尺度特性是否相同”这个角度来区分的只要两个参考信号经历的信道响应可以认为是相同的它们就可以映射到同一个天线端口上。DMRS端口编号从1000开始比如PDSCH的DMRS端口从1000到1011PUSCH的从0到11实际传输的时候会用DMRS端口到物理天线端口的映射关系做预编码。在MU-MIMO场景下两个用户可能各自只有一根物理天线但基站会给它们分配不同的DMRS端口这样基站接收时就能把两个用户的数据流区分开。所以在做协议栈或者物理层算法时不要直接把DMRS端口等同于物理天线数量它是逻辑概念真正的映射关系在CSI-RS、SRS和预编码矩阵之间会有一些列的换算。加扰IDScrambling ID也是个容易被忽略的配置。DMRS序列本身是伪随机序列初始化的时候需要种子这个种子由加扰ID、小区ID、时隙号、符号号联合生成。网络可以给不同的用户配置不同的加扰IDnID目的是降低来自邻区的干扰两个相邻小区即使用了相同的时频资源和端口只要加扰ID不同它们之间的DMRS相关性就会比较低干扰被随机化。实际优化时如果发现某些区域的SINR持续偏低、且BLER不达标可以考虑检查邻区间的加扰ID规划。3. DMRS参数配置实战从RRC信令到实际调优的全过程3.1 DMRS类型选择Type 1和Type 2到底怎么取舍RRC层控制DMRS配置的核心字段在PDSCH-Config和PUSCH-Config里其中dmrs-Type支持两种枚举值type1和type2。选Type 1还是Type 2主要看当前小区的负载和预期的MU-MIMO配对层数。Type 1在频域上更密集信道估计精度在低秩传输时更好适合小区边缘用户或者信道质量较差的场景。Type 2在频域上稀疏一些但支持更多的正交端口适合小区中心用户和MU-MIMO高配对需求的场景。实际商用网络的典型做法是宏站边缘用户多倾向于Type 1室内热点和小站MU-MIMO配对收益明显倾向于Type 2。不过这个也不是绝对的需要结合终端的移动速度和信道环境来定。还有一个细节Type 1和Type 2都支持单符号和双符号DMRS配置。单符号配置下DMRS只占一个OFDM符号开销小但端口数受限Type 1是4端口Type 2是6端口双符号配置下DMRS占两个OFDM符号端口数翻倍Type 1是8端口Type 2是12端口但开销也翻倍。选择时要注意maxLength字段它指示的是“最多能用到几个符号”实际调度时网络会根据秩指示和端口需求动态决定是单符号还是双符号。3.2 前置位置参数如何与调度模式配合dmrs-TypeA-Position这个参数看似简单但和调度模式紧密相关。它只能取2或3表示在时隙的第二个还是第三个OFDM符号放置前置DMRS。如果符号2上有PDCCH控制资源集CORESET占用了前置DMRS就会被推到符号3否则一般优先用符号2因为越靠前解调时延越低。这里还有一层逻辑Type A的“A”指的是调度是基于时隙级别的也就是PDSCH的起始符号和数据持续时间在一个时隙内是比较规矩的而Type B的“B”是非时隙级调度PDSCH可以在时隙内的任意符号位置启动比如URLLC的迷你时隙调度数据可能只占2个或4个符号这时DMRS就必须放在数据符号的第一位置上不能按Type A的固定位置来。实际排障里我已经见过好多次了某些终端在特定调度模式下解调失败查来查去发现是基站侧的dmrs-TypeA-Position配置为3但PDCCH只占了符号0和符号1实际上可以用2导致数据符号少了一个吞吐率掉了7%左右。这个参数一般运营商都会在系统消息里广播修改的时候要通知到所有终端影响面比较大不是特殊情况不建议动。3.3 从日志里看DMRS配置协议栈和优化人员都得会的技能在做协议栈开发和网络优化时你需要能从信令或日志里读出当前DMRS配置。NR的RRC重配置消息里PDSCH-Config和PUSCH-Config节点下的dmrs-UplinkForPUSCH-MappingTypeA、dmrs-DownlinkForPDSCH-MappingTypeA这些字段一层层往下翻就能看到dmrs-Type、dmrs-AdditionalPosition、maxLength、scramblingID0/1这些参数。比如用一个简单的ASN.1日志解析工具把RRCSetup或RRCReconfiguration里的PDSCH配置解出来大概是这样的结构pdsch-Config dmrs-DownlinkForPDSCH-MappingTypeA dmrs-Type: type2 dmrs-AdditionalPosition: pos2 maxLength: len2 scramblingID0: 1234 scramblingID1: 5678看到dmrs-Type是type2说明这个小区采用4梳结构dmrs-AdditionalPosition是pos2说明除了前置DMRS之外还有2个额外DMRS符号maxLength是len2说明调度器最多可以用双符号DMRS。这些信息组合起来你就能大概判断出这个小区是偏向高配对还是高覆盖。如果优化时发现边缘用户SINR不行但小区里配置的是Type 2加双符号可能就需要考虑降级到Type 1把宝贵的RE让给数据。手动抓日志太麻烦的话也可以用脚本自动筛选。比如在协议栈日志文件里用正则表达式匹配dmrs相关字段把每个小区的配置汇总成表格对比不同小区之间的差异。我一般用下面这条命令快速抓取关键字段grep -E dmrs-Type|dmrs-AdditionalPosition|maxLength|scramblingID -A 2 rrc_log.txt这样可以快速定位到每个小区的DMRS配置做批量对比分析。对于搞优化的人来说这一步的价值在于能快速发现参数配置不一致的问题比如同一个基站下三个小区两个配置了Type 1一个配了Type 2用户切换过去之后性能容易出现跳变。4. DMRS对系统性能的影响吞吐率、波束管理和MU-MIMO都靠它4.1 峰值速率计算里DMRS开销怎么算这个坑很多人都踩过5G的峰值速率计算有一个标准公式在3GPP TR 37.910里给得很清楚但很多人在实操时都忽略了DMRS开销这一项导致算出来的理论峰值偏高。如果你在做链路预算或者峰值速率测试DMRS开销量必须考虑进去。先看基础参数。以100MHz带宽、子载波间隔30kHz的典型配置为例一个时隙是0.5ms总共有273个资源块RB。一个RB是12个子载波一个时隙14个符号所以一个RB总共有168个RE。如果DMRS是Type 1、单符号、映射Type A那么前置DMRS占用的RE数是一个符号里12个子载波的一半也就是6个RE再乘以12个RB这里说的是每个RB里实际就是每RB每个DMRS符号占6个RE。如果还开了额外DMRS比如配置了1个额外位置那就是再增加6个RE。单符号Type 1的DMRS开销大概在6/168约等于3.6%听起来不算高。但要注意如果开了双符号DMRS开销直接翻倍到7.1%左右。如果用Type 2双符号、并且配置了3个额外位置DMRS符号总数可以达到4个那开销就非常可观了4个DMRS符号里每RB占用的RE是8个Type 2每符号4个RE乘以24个符号就是16个RE16/168约等于9.5%。如果再加上PDCCH、CSI-RS、SSB的开销实际可用RE比例会进一步下降。所以你在算峰值速率时公式里的可用RE要按实际配置去折算不能直接把总RE数当数据RE数。用标准公式套一下峰值速率 每RB的数据RE数 × RB数 × 每时隙符号数相关的有效比例 × 调制阶数 × 编码率 × 层数 × 时隙数每秒以100MHz带宽、273个RB、64QAM调制阶数6、编码率948/1024约0.926、单用户4层、30kHz子载波间隔、每时隙可用RE扣除约10%开销为例理论峰值大概在2.1Gbps左右。如果DMRS配置从单符号Type 1变成双符号Type 2加2个额外位置开销可能从不到4%升到7%以上峰值速率会下降2%到3%在大规模测试中这个差异是能明显测出来的。4.2 DMRS和波束管理、QCL的关系5G NR在毫米波频段依赖波束成形来对抗高路损而波束管理里有一个绕不开的概念叫QCLQuasi Co-Location准共址。QCL描述的是两个参考信号之间的大尺度参数是否相同比如多普勒频移、多普勒扩展、平均时延、时延扩展、空间接收参数这五个维度。DMRS和CSI-RS、SSB之间的QCL关系决定了终端用哪个接收波束去解调PDSCH。在一个典型的波束管理流程里基站先通过SSB做初始波束扫描终端上报最优SSB索引然后基站通过CSI-RS做精细波束训练最终选定一个CSI-RS作为PDSCH DMRS的QCL源。这个QCL关系在DCI里通过传输配置指示TCITransmission Configuration Indicator字段告知终端。终端收到TCI后就知道用和这个CSI-RS相同的接收波束来收PDSCH的DMRS。我在做毫米波测试时遇到过一个问题基站配置了多个TCI状态但某个状态的QCL源指向的CSI-RS功率很低终端在切换波束后信道估计质量突然变差。查了半天发现是CSI-RS的功率偏置配置不对导致终端估计的信道质量虚高实际解调时DMRS的SINR和预期对不上。所以做波束管理优化时不仅要看DMRS配置本身还要检查TCI状态里QCL源的选择和功率配置尤其是多TRP传输接收点场景下不同TRP之间的QCL关系更容易出错。4.3 DMRS配置对移动性场景的影响高铁场景的配置经验在高速移动场景下DMRS的额外位置配置直接决定了信道估计能否跟上信道变化。高铁场景中终端速度一般300km/h以上多普勒频偏可能超过1500Hz3.5GHz频段下车速300km/h时的多普勒频偏约970Hz信道在一个时隙0.5ms内的相干时间大约是0.5ms级别也就是说信道在一个时隙内就会发生显著变化。这时候如果只配置前置DMRS时隙后半段的数据解调性能会明显下降因为接收机用前置DMRS估计出来的信道已经过时了。解决办法就是把dmrs-AdditionalPosition配置到2或3让DMRS符号在时隙内均匀分布定时跟踪信道变化。但这会带来一个副作用DMRS开销量增加可用数据RE减少单用户峰值速率下降。另一个经验是高速场景下尽量用Type 2的4梳结构因为Type 2在频域上的DMRS密度较Type 1稀疏在时变信道下对频域选择性的估计能力稍弱一点但这种场景下时域跟踪比频域细分更重要所以Type 2反而更合适。不过这个结论不是绝对的具体还是要看小区覆盖和用户分布。我在实际高铁专网的优化中一般建议把额外位置配2前端位置配3避开PDCCH这样在吞吐率和解调性能之间能取得相对平衡。5. DMRS常见问题与排查技巧实录5.1 DMRS相关故障速查表日常优化和协议栈开发里DMRS相关的故障其实有很强的典型性我总结了一个速查表遇到类似问题可以先按这个思路排查。现象可能原因排查方向用户SINR正常但BLER高DMRS端口冲突或OCC正交性受损检查MU配对用户是否同CDM组尝试降低配对层数边缘用户解调失败DMRS类型配置不当频域密度不足切换到Type 1或增加额外DMRS位置高速场景下时隙后半段误码率高额外DMRS位置太少调大dmrs-AdditionalPosition波束切换时突然掉线TCI状态的QCL关系错误检查TCI配置和CSI-RS功率偏置系统总吞吐率低于理论值DMRS开销过大检查maxLength和额外位置是否过配邻区干扰导致SINR虚高但解调失败加扰ID规划不合理检查邻区间加扰ID配置是否差异化这张表不是万能药但能帮你在故障排查时快速锁定方向不用上来就抓空口报文慢慢看。5.2 信道估计总失败问题可能不在DMRS本身做物理层算法的人应该都有这个体会信道估计失败第一反应是检查DMRS序列生成是否正确但最后往往发现是时频资源映射错了。我在调试过程中踩过好几次类似的坑最常见的是DMRS符号位置和速率匹配没对齐。NR的速率匹配Rate Matching机制会根据实际分配的DMRS资源把数据RE中那些被DMRS占用的位置空出来。如果协议栈在速率匹配时用的DMRS配置和物理层实际映射的DMRS配置不一致那接收端在解速率匹配时就会错位整个传输块解码失败。这种问题在跨厂商对接时特别容易出现因为双方对配置字段时间的解释可能不一致。排查这类问题的方法很直接把发射端的DMRS映射图案和接收端期望的图案对比一下看符号位置和子载波索引是否一致。如果基站侧PDSCH用Type 1前置位置在符号2、额外位置在符号11但终端按Type 2、负责位置在符号3去接收那必然解不出来。5.3 几个我反复用到的调优经验第一个经验是先看DMRS开销再谈优化。很多人一上来就追求满配把所有额外DMRS位置打开结果单用户峰值速率掉了一大截。我的做法是先根据场景定需求城区低频段低速用户多额外位置配0或1高铁、高速路场景配2或3室内微站因为信道变化慢配0就够了。第二个经验是DMRS和CSI-RS要联动看。DMRS负责解调CSI-RS负责信道质量测量和波束管理两者的端口配置和功率偏置如果不对齐终端上报的CQI和价值实际情况会差很多。比如CSI-RS发送功率比数据信号低终端解出来的SINR偏低上报CQI后基站用了低MCS吞吐率就上不去。所以调DMRS时顺手看看CSI-RS的功率配置。第三个经验是做MU-MIMO配对时尽量把不同用户分配到不同CDM组。同CDM组内的端口用OCC区分虽然正交但对时频偏和信道估计误差非常敏感。如果两个用户在同一个CDM组它们的信道响应差异较大OCC正交性就被破坏解调性能会急剧恶化。实际调度时优先让同一CDM组里的用户保持较低的相关性这比单纯追求高配对层数更稳妥。第四个经验是遇到SINR很高但吞吐率上不去的案子先查DMRS加扰ID是否一致。同一小区下两个用户如果被配了相同的加扰ID又正好在资源上重叠DMRS会强相关接收机区分不了就像两个人同时说一模一样的话虽然音量很大但根本听不清谁是谁。这种问题在优化中最常见也最容易忽略第一步往往是看加扰ID规划表。我自己做过的项目里有一回在某个宏站片区做容量优化用户反映下行速率波动大从日志看DMRS配置正常SINR报告也在20dB以上但BLER始终在10%左右徘徊。查了半天最后发现是两台中兴和华为的基站在同一区域覆盖某个终端切换后加扰ID没有及时更新老小区的加扰ID沿用到了新小区导致DMRS干扰。调整邻区加扰ID配置之后问题立刻消失。还有一次是做终端吞吐率测试终端报告下行速率只有理论值的一半查协议栈日志发现调度器给终端配了双符号DMRS和3个额外位置但实际数据不到14个符号额外DMRS占了太多数据RE。后来手动把额外位置从3降到1速率马上提升了约6%。这说明配置不是越大越好适配场景才是关键。从这些经验来看DMRS在协议栈里是静态参数但在实际网络运行中其实非常动态。做开发、做优化、做测试的人都需要在“理解机制”和“动手调参”之间来回切换才能真正把这个参考信号用好。希望这篇文章能帮你在面对DMRS问题时少走一些弯路。