1. 先从一次拉网测试说起DMRS到底管什么用有一回在现网做拉网测试终端显示的RSRP很漂亮-85dBm左右SINR也有十几但下行速率就是上不去MCS被压到10以下PDSCH解调频频出错。排查了半天后台把调度记录、PRB利用率和干扰矩阵都翻了一圈最后发现问题出在DMRS上邻区有个站点用了相同的加扰IDDMRS端口又在时频资源上撞了车导致终端做信道估计时拿到的参考序列已经“脏”了。这件事之后我每次看优化问题都不再只盯着SSB和CSI-RS而是把DMRS的配置一起拉出来。DMRS全称Demodulation Reference Signal解调参考信号是NR里跟着PDSCH/PUSCH一起走、专门用来做信道估计的参考信号。你可以把它理解成发送端给接收端塞进数据流里的一套“校正尺子”数据在空间传播时被信道搅了一遍接收端靠这根尺子反推出信道变成什么样然后把数据修正回来。没有DMRS终端解调就是个盲猜MIMO、波束、高阶调制全都玩不转。这篇内容适合三类人看刚上手NR协议栈的研发和测试工程师做基站或终端参数配置的协议工程师以及天天和拉网、吞吐率、干扰问题打交道的网优工程师。理解了DMRS的核心机制你才算真正看懂调度记录里那些“dmrs-Type”“additionalPosition”字段在干什么也才知道现网那些“信号好但速率差”的疑难杂症该怎么下手。2. DMRS工作原理序列、映射和资源占用的底层逻辑2.1 NR里为什么没有LTE那种“常驻”参考信号LTE时代还有CRSCell-specific Reference Signal一直跟着每个子帧发人人都能用它做测量、解调代价就是它永远占着开销而且跟波束赋形天生八字不合。NR为了支持大规模天线阵列和灵活的波束调度把通用参考信号砍掉了改用按需发送的DMRS只有调度了数据DMRS才出现而且它和数据的预编码、波束方向完全保持一致。这意味着DMRS是“跟着调度走”的没有对应数据资源就没有DMRS。好处是开销极低调度器想省资源就省资源坏处是终端没法拿DMRS做小区测量所以才需要SSB和CSI-RS去承担驻留、波束测量和信道质量反馈的职责。三者的关系经常有人搞混SSB负责“找到小区、初测波束”CSI-RS负责“测量信道质量、上报CQI/PMI/RI”DMRS负责“真正干活解调数据”。排查问题时如果先分清是哪一层失守能省不少时间。2.2 DMRS的序列生成ZC序列、低峰均比与加扰IDDMRS序列不是随便弄的伪随机码NR里PDSCH/PUSCH的DMRS用的是低峰均比low-PAPR序列最常见的实现是ZC序列Zadoff-Chu。为什么必须用这种序列一是因为它的自相关和互相关特性好接收端在时频偏移、多径环境下依然能准确识别出参考信号二是因为峰均比低对上行尤其重要终端功放的效率不会因为发参考信号而严重下降。序列的根序列索引、组跳频和序列跳频参数决定了一组基站下面能用多少正交的DMRS。参数里有个加扰IDscramblingID标准里给基站预留了两个ID可以配。实际现网中邻区之间如果这两个ID选得不好又叠加了相同的端口和频域位置就会出现我开头说的“DMRS互扰”。所以做频点规划的人会把这些ID当成频率规划的一部分去梳理而不是让基站随便给一个默认值。2.3 DMRS占多少资源密度、端口与开销到底怎么算DMRS映射到资源网格时在频域上采用“梳齿”结构时域上占用一个或者两个连续的OFDM符号。无论是配置类型1还是类型2本质上都是在空中资源里“打格子”每PRB、每个DMRS符号里挖出若干个资源元素放参考信号剩下的RE继续放数据。打格子的疏密直接决定单端口开销和可容纳的正交端口数。先给一个直觉100MHz、30kHz子载波间隔、常规14符号时隙如果只配前置一个DMRS符号、只用1个CDM组DMRS的开销大致是2%-4%量级如果把配置类型1的双CDM组打开或者再加一个额外DMRS位置开销立刻翻倍到7%甚至10%以上。对峰值速率来说这一点都不能小看。后面第5部分我会用一个实际的速率计算公式把DMRS开销的影响演示出来。3. 配置类型与参数细节Type 1/Type 2、额外位置与端口机制3.1 dmrs-Type、maxLength和TypeA/TypeB映射怎么理解对PDSCH来说RRC层会针对不同的映射类型分别下发一套DMRS配置。最常见的两个参数是dmrs-Typetype1或type2和maxLengthlen1或len2。len1表示每个DMRS symbol位置只放1个单符号len2则表示在该位置放连续两个符号端口数可以翻倍但开销也翻倍。映射类型TypeA和TypeB的区别在于前置DMRS放在哪。TypeA的前置位置相对时隙起始位置固定通常在符号2或3由dmrs-TypeA-Position参数决定适合以时隙为单位的常规调度URLLC、eMBB都常见TypeB则把前置DMRS放在实际数据调度的第一个符号上适合短调度、低时延业务因为不用等一个固定的符号位置调度多短都能立刻带上参考信号。现场处理低时延业务速率不达标时我习惯先看这个映射类型和调度的符号数是否匹配。TypeB如果配了过多additionalPosition低时延小包场景反而白白浪费开销反过来TypeA配了pos0高速用户又可能因为信道估计跟不上而误码。3.2 配置类型1和类型2正交端口数、密度和适用场景Type 1和Type 2最大的区别在频域密度和可支持的端口数。业界常说的结论是Type 1单符号下支持4个正交端口双符号下支持8个Type 2单符号下支持6个双符号下支持12个。Type 1每个正交端口下放到单PRB里的参考信号RE更密单端口信道估计精度好特别适合Rank较高的单用户MIMOType 2则用更稀疏的RE换来更多正交端口适合多用户MIMO场景多个用户并行调度时能分配不同的正交DMRS端口彼此不打架。网络规划里没有绝对的“Type 1更好还是Type 2更好”的说法。你所在厂商的推荐基线、现网配对的用户数、小区典型Rank分布都会影响选择。我见过不少站点为了省配置时间一直用默认Type 1结果小区多用户配对时端口不够调了半天还是没用上Type 2的12端口能力。3.3 额外DMRS位置additionalPosition到底该怎么选额外DMRS位置dmrs-AdditionalPosition解决的是信道随时间变化快的场景。前置DMRS只在调度开头附近出现如果数据调度跨了整个时隙而信道在中间已经变了大样后续数据的信道估计就会越来越不准。这时候调度器就在数据中间加插一个或多个DMRS符号让终端能“刷新”信道估计。实际选多少取决于移动速度、调度持续符号数和是否需要跳频。3GPP协议里有一张查表关系不同的additionalPosition取值和不同调度符号数下额外位置的数量和位置都跟着变。这里不背那张表你只要记住三句话调度符号数越短能放的额外位置越少additionalPosition配得越高开销越大开跳频时每个跳频段里都至少要有一个DMRS否则跳完频就无法解调。高铁场景通常至少额外位置配到pos1或pos2和调度选长符号配置配合室内低速场景则优先用pos0把开销压到最低。4. 不同业务场景下的DMRS实践MIMO、移动性、跳频和波束管理4.1 PDSCH/PUSCH里的DMRS应用细节PDSCH的DMRS由gNB调度终端被动接收配置通过RRC半静态下发再由DCI动态选择端口。上行PUSCH的DMRS稍微复杂一点因为终端功率受限DMRS的功率密度直接影响信道估计质量。配置PUSCH DMRS时不但要看正交端口和开销还得考虑功率谱密度如果DMRS占的RE太少同样功率摊到每个RE上很足看起来是好事但调度数据的能力也下降了占得太多数据RE被挤压速率下来。实际就是找平衡。另外上行多用户MIMO里不同终端如果被调度在相同的时频资源上每个终端必须用不同的DMRS正交端口或不同的梳齿位置否则gNB收到的参考信号混在一起上行信道估计直接崩。这是基站调度器MU-MIMO配对前必须检查的约束条件。我在做外场拉测时经常看到后台调度记录里出现“MU配对失败端口冲突”的日志大多数就是DMRS端口配置没分配好。4.2 高速移动场景多普勒频移和额外DMRS的配合高速场景是DMRS配置最讲究的场景之一。列车跑350km/h时信道在几毫秒内可能发生明显变化前置DMRS估计出的信道到时隙后半段已经过期了。这个时候除了配置额外的DMRS位置外还要注意子载波间隔的选择30kHz对比15kHz有更短的符号时长能抵抗一定多普勒扩展但要牺牲覆盖。不同厂家的高铁方案里DMRS额外位置和SCS往往是联调出来的而不是单独拍脑袋。实际排查高铁线路问题时有个很容易忽视的点调度器会把高铁用户尽量调度到长时隙以获取更高的频谱效率但这也拉长了信道有效期反而对额外DMRS位置的需求更急。如果你看到高铁用户在长调度上误码率偏高、MCS回退厉害先不要急着怀疑设备去看一眼这一次调度里到底落了几个DMRS符号大概率能找到线索。4.3 上行跳频场景跳频段与DMRS的约束关系NR支持上行频域跳频主要目的是获得频率分集增益同时对抗窄带干扰。但跳频引入一个约束跳频发生前和发生后接收端都需要能在新的频段上重新做信道估计否则这一段数据解不出来。协议上要求调度期内每个跳频段内都有足够DMRS支撑解调这直接和additionalPosition的配置绑定。我踩过一个坑某项目为了提升上行速率把PUSCH开了跳频但DMRS额外位置配得太低调度时长一拉长每个跳频带里只有开头一个前置DMRS后半段解调性能大幅下降上行误块率飙升。后来把additionalPosition调高一档、把跳频带宽和时隙长度的配比重新算了一遍问题才稳定下来。4.4 波束管理场景SSB、CSI-RS和DMRS如何分工NR高频段必须靠波束补偿路径损耗。SSB负责小区发现和初始波束扫描CSI-RS负责精细波束测量和上报而DMRS只负责在选定波束下解调实际数据。这三者就像“先找到人、再试方向、最后递货”的关系SSB找到你在哪个方向CSI-RS试哪个方向信号最好DMRS则沿着选定的方向把数据准确送到你手上。这就理解了为什么波束赋形出现问题时SSB的RSRP可能还挺好数据面却烂得不行因为同步和测量信号走的是宽波束而PDSCH用窄波束如果窄波束指偏了DMRS和随之而来的数据都会被“晾”在错误的增益上。优化时看到“SSB RSRP正常但PDSCH BLER高”的经典局面一半以上要去查波束管理和DMRS的对应关系。5. 从排障和速率公式看DMRS的实际影响调优经验分享5.1 现网排障DMRS干扰、端口碰撞和MCS回退现网信号好但速率差如果已经排除了普通邻区干扰下一步就该看DMRS级别的冲突。常见情况是邻区间用了相同的加扰ID和相近的DMRS端口大业务量时两个小区的DMRS在相同时频资源上重叠互相污染。从后台指标表现看通常会看到PDSCH的MCS被压低、误块率虚高而SSB RSRP和CSI-RS SINR却一切正常。处理办法没有太多黑科技就是“错开”给邻区配不同的加扰ID、不同的CDM/端口偏置实在不行就错开PRB调度。高级一点的思路是结合干扰协调比如几乎空白子帧、功率控制给DMRS创造干净的资源窗口。我在拉网时遇到类似的“看不见的干扰”最后都是靠把两站DMRS参数对齐比对才揪出来的所以强烈建议在工参数据库里把DMRS相关的配置字段一并管理起来。5.2 结合峰值速率计算公式看DMRS开销的量化影响说到峰值速率不少人都听过3GPP的估算方法先看子载波数再看每时隙符号数乘上调制阶数和层数再乘编码率最后扣掉各种开销。简化写就是峰值速率 PRB数 × 12子载波/PRB × 每时隙符号数 × 调制阶数 × 编码率 × 层数 / 时隙时长 × (1 - 控制信道和参考信号开销)我以一个典型配置举例FR1100MHz30kHz SCS273 PRB每时隙14符号256QAM8bit/RE编码率0.9264层MIMO时隙时长1ms总开销系数按14%算。速率算出来大约是1.17Gbps左右和网上给的理论峰值很接近。这里“总开销系数”里DMRS占了大头而且是调度行为直接决定的单符号单CDM组和双符号双CDM组之间速率差距可能到几十Mbps甚至上百Mbps。在生产环境看峰值速率时我建议把DMRS开销单独拉出来算一遍数一次调度里放了几个DMRS符号、用了几组CDM然后按比例加到开销里去。这样看到测速不达标时能快速判断是DMRS配置偏重了还是真的其他环节受限。5.3 开源协议栈里的DMRS调试经验OAI等平台怎么用搞协议栈研究的人可能更熟悉OAI等开源5G平台。在这些环境里gNB和UE之间任何DMRS参数不一致都会造成解调失败典型的错法是gNB侧下发dmrs-TypeA-Positionpos2UE侧却按pos3去盲检结果前面几个符号的信道估计全错PDSCH解调连续失败。这类问题在仿真里经常表现为“随机性误码”非常迷惑人。我的习惯是在开源平台上做DMRS实验时先把RRC配置打印到日志里逐字段对齐特别是scramblingID、dmrs-Type、maxLength、additionalPosition这四项。改配置时不要一次改多项否则出了问题很难定位是哪一项带崩的。另外如果开了CU/DU分离架构RRC重配置下发会有时延UE如果没跟上新配置DMRS端口会短暂错乱这在模拟环境里也常被当成信道问题排查半天。6. 一页纸总结高频踩坑点与参数解读速查6.1 高频踩坑清单DMRS相关的现网和协议栈问题其实有很强的共性这里把最常见的几类攒成一张速查表拿到现场可以直接对照。现象排查方向常见根因RSRP/SINR都正常但PDSCH MCS偏低DMRS端口/加扰ID冲突邻区互扰邻区scramblingID相同、DMRS端口时频重叠高速移动下BLER升高、速率波动额外DMRS位置不足、SCS选择不当additionalPosition配pos0或过低MU-MIMO配对后用户速率下降正交端口不够、DMRS开销变大Type 1端口不足双符号DMRS密度过高上行跳频段解调失败每个跳频段缺少DMRSadditionalPosition和跳频调度长度不匹配开源平台随机性解调失败gNB和UE的DMRS参数不一致TypeA位置、scramblingID、maxLength不同步高频波束下窄波束指偏SSB正常但PDSCH解调差波束管理和DMRS随数据传输方向未对齐6.2 快速解读一份DMRS配置需要看什么拿到一份基站侧DMRS配置我一般先看四件事看映射类型是TypeA还是TypeB能判断调度风格看dmrs-Type是1还是2能判断单用户多流还是多用户配对为主的倾向看additionalPosition是pos0还是更高能判断设计者有没有考虑移动性和跳频看maxLength是len1还是len2能判断端口容量够不够、开销舍不舍得。这四个字段看完整站的数据面调性基本就清楚了。如果再加一项我会看加扰ID在邻区之间是不是错开的。很多默认基线配置不会自动做这个检查等到出了干扰问题才回头追时间成本就上去了。建议把它写进网络规划的核查模板里和PCI、PRACH、CSIRS这些规划项同等对待。根据我个人做协议和网优的经验DMRS这类跟着数据走的参考信号最大的坑在于它不像SSB那样可以一眼从扫频图上看到很多参数问题都藏在调度过程和RRC信令里。排查时别只看平均指标最好抓一段问题时段的详细调度记录确认DMRS符号位置、端口、加扰ID这些字段的真实下发情况。很多时候所谓“玄学掉速”本质就是参考信号在某个细节上没对齐。