当前位置: 首页 > news >正文

一文讲清 PUSCH DM-RS 的 FD-OCC、TD-OCC 与端口关系

PUSCH DM-RS 的多端口区分,不是“每个端口换一条完全不同的长序列”这么简单。3GPP 通过频域偏移、频域正交覆盖码 FD-OCC、时域正交覆盖码 TD-OCC,给每个 DM-RS port 分配一组可预测且正交的签名。

本文聚焦 NR PUSCH DM-RS,依据 3GPP TS 38.211 §6.4.1.1.3 及表 6.4.1.1.3-1/-2 说明 FD-OCC、TD-OCC 如何工作,以及它们与 DM-RS port 的关系。

1. 先分清:DM-RS port 不是物理射频天线

p=0,1,2,...DM-RS antenna port 索引,它描述参考信号在时频资源上的可分离特征;它不应被直接理解为“UE 上第几根物理天线”。

PUSCH DM-RS 的处理顺序更接近:

基础 DM-RS 序列 r(n) ↓ 按 DM-RS port p 施加 (λ, Δ, w_f, w_t) ↓ 得到每个 port 的时频 DM-RS a(k,l,p) ↓ 经过预编码矩阵 W ↓ 映射到实际发射天线端口

因此,DM-RS port 是“可用于信道估计的逻辑参考信号端口”;物理天线上的实际发射信号还要经过预编码矩阵 W。端口之间是否可分离,首先由 DM-RS 的时频签名决定。

2. FD-OCC 和 TD-OCC 到底做了什么?

对一个 DM-RS port,标准映射的核心结构可以抽象为:

其中:

  • :已经生成好的基础 DM-RS 序列;
  • :port p 的FD-OCC,作用在同一 DM-RS symbol 内的一组频域 RE 上;
  • :port p 的TD-OCC,作用在一对 DM-RS OFDM symbol 上;
  • :port 对应的频域偏移;
  • :CDM group(码分复用组)索引。

2.1 FD-OCC:在同一 DM-RS symbol 内“加正负号/相位”

以最常见的两项 FD-OCC 为例,port 0 与 port 1 可使用:

它们在两个频域位置上的内积为零:

因此,接收端在对应 RE 上按已知的 [1,1] 或 [1,-1] 相关/解扩,就能把同一 CDM group 中的两个 port 分离出来。标准的增强配置还可使用四项、含 j 的频域 OCC;原理仍是“已知的正交相位模式”。

2.2 TD-OCC:在两个 DM-RS OFDM symbol 之间“翻相”

TD-OCC 的典型两项码为:

它要求 DM-RS 有可配对的两个 OFDM symbol。第一个 port 在两符号上同相,另一个 port 在第二个符号翻相;接收端对两个符号作加/减即可解扩。

这也是一个重要限制:单符号 DM-RS 不能从 TD-OCC 获得额外正交维度;只有双符号 DM-RS 时,w_t=[1,-1] 这类端口签名才有意义。

3. 端口的“签名”:(\lambda,\Delta,w_f,w_t)

把每个 DM-RS port 看成一个四元组最清楚:

元素作用端口间的意义
CDM group \lambda标识码分复用组不同组通常配合不同频域偏移,占用不同 RE 子集
频域偏移 \Delta决定 DM-RS 从哪一类子载波位置开始映射先在 RE 位置上分开端口组
FD-OCC w_f在一个 DM-RS symbol 的频域 RE 上覆盖分离同组、同偏移的端口
TD-OCC w_t在一对 DM-RS symbol 上覆盖双符号 DM-RS 时进一步扩展正交端口

所以,两个端口只要四元组中有一项不同,就可能具备可区分性;但最终可支持哪些 port 组合,仍由 38.211 的表格和 38.214 的调度约束共同限定。

4. configuration type 1:端口 0 到 7 如何用 FD-OCC/TD-OCC 区分?

以常规 PUSCH DM-RS configuration type 1 为例,频域采用 Comb-2 结构。基本端口组合可以这样理解:

DM-RS port\lambda\DeltaFD-OCC 的典型前两项TD-OCC与谁构成正交对
000[1,1][1,1]与 port 1 作 FD-OCC 正交
100[1,-1][1,1]与 port 0 作 FD-OCC 正交
211[1,1][1,1]与 port 3 作 FD-OCC 正交;与 0/1 的 RE 位置也不同
311[1,-1][1,1]与 port 2 作 FD-OCC 正交
400[1,1][1,-1]与 port 0 主要通过 TD-OCC 区分
500[1,-1][1,-1]与 port 1 主要通过 TD-OCC 区分
611[1,1][1,-1]与 port 2 主要通过 TD-OCC 区分
711[1,-1][1,-1]与 port 3 主要通过 TD-OCC 区分

这里能看到很清晰的层次:

  1. port 0/1 共享,仅用 FD-OCC [1,1] 与 [1,-1] 分开;
  2. port 2/3 改为,先换到另一组频域 RE,再用 FD-OCC 分开;
  3. port 4--7 复用 0--3 的频域特征,但把 w_t 从 [1,1] 改成 [1,-1],因此需要双符号 DM-RS。

换句话说,FD-OCC 每个 CDM group 内提供频域正交维度;TD-OCC 再把同一频域签名复制到第二个时间正交维度。

5. configuration type 2:为什么会有三个 CDM group?

对于未启用 transform precoding 的 PUSCH,DM-RS configuration type 2 采用“每 6 个子载波内两个相邻 RE”的资源结构。表 6.4.1.1.3-2 的基本端口关系为:

端口对\lambda\DeltaFD-OCC 对
port 0 / 100[1,1] / [1,-1]
port 2 / 312[1,1] / [1,-1]
port 4 / 524[1,1] / [1,-1]

三个对应三组不同的 RE 位置;每一组内部再用 FD-OCC 分出两个 port。双符号 DM-RS 时,port 6--11 进一步使用 w_t=[1,-1],在每个频域端口对的基础上增加 TD-OCC 正交维度。

与前一篇 transform-precoded PUSCH DM-RS 的说明保持一致:启用 transform precoding 时使用 Comb-2 / configuration type 1 的映射;本节的 configuration type 2 端口关系用于理解一般的、未启用 transform precoding 的 PUSCH DM-RS 映射。

6. 接收机如何“看到”这些正交码?

忽略噪声并假设两个 DM-RS symbol 所经历的信道在可解扩窗口内近似可推断,接收端可把接收资源乘以本端口已知的共轭 OCC,再跨相应频域 RE 和时域 DM-RS symbol 累加:

其他端口的 OCC 与目标端口正交时,其和会相互抵消;目标 port 的项则相干累加。这正是 FD-OCC/TD-OCC 能让多个 DM-RS port 共享有限 RE 的原因。

实际信道会有频率选择性、时变和噪声,因此“正交”不是无条件的:TD-OCC 尤其依赖两个 DM-RS symbol 间的信道可推断性。这也是标准会同时规定 DM-RS symbol 位置、最大前置 DM-RS 长度和端口组合的原因。

7. 实现与排障的四步检查

  1. 先确认 PUSCH 是否启用 transform precoding;若启用,只按 Comb-2 / configuration type 1 处理;
  2. 从相应 configuration type 的表中,按 port 读取
  3. 单符号 DM-RS 时不要分配依赖 w_t=[1,-1] 的端口;双符号 DM-RS 才可使用 TD-OCC 扩展;
  4. 在接收端用目标 port 的共轭 FD-OCC/TD-OCC 解扩,并检查相邻 DM-RS symbol 的信道时变是否过快。

8. 小结

FD-OCC、TD-OCC 与端口的关系可以压缩成一句话:

DM-RS port 由 () 唯一刻画:\Delta 和 \lambda 先划分 RE 组,FD-OCC 在频域分开同组端口,TD-OCC 在双符号 DM-RS 时再增加一层端口正交。

所以,端口正交不是单靠“不同序列”实现的,而是序列、RE 位置、频域 OCC 与时域 OCC 共同构成的结果。

参考规范

  • 3GPP TS 38.211,NR; Physical channels and modulation:§6.4.1.1.3、表 6.4.1.1.3-1、表 6.4.1.1.3-2;
  • 3GPP TS 38.214,NR; Physical layer procedures for data:PUSCH DM-RS port、transform precoding 及相关调度约束;
  • 3GPP TS 38.331,NR; Radio Resource Control (RRC) protocol specificationDMRS-UplinkConfig配置。

实际实现与一致性测试应以目标 Release 对应的正式规范版本、端口表与 DCI 天线端口指示为准。

http://www.cnnetsun.cn/news/3552821.html

相关文章:

  • C++20协程实战:从原理到异步IO编程的三大应用案例
  • Python编程入门:从零基础到实战项目的学习路径
  • LangChain核心解析:LLM应用开发的标准化工具
  • 黑苹果EFI工具详解:OpenCore配置与硬件兼容性指南
  • 汽车图像缩放技术:从YUV格式到TI Jacinto RSZ硬件实现
  • C++数据类型深度解析:从内存布局到实战避坑指南
  • Jetson TK1无线网卡实战:Intel 7260 AC双频WiFi适配指南
  • 企业信用与工商信息采集:构建企业关系网络图谱与智能风控平台
  • C++实现Tamura纹理特征:从原理到工程实践
  • 大模型学习路线:从零基础到工业级部署
  • 基于 SpringBoot 的智慧柳州旅游景点导游平台
  • AI短剧系统私有化部署与零代码开发指南
  • 南洋理工大学Advanced Science:花粉增强仿生触觉感受器,助力新一代感知增强假肢
  • PAM360:现代企业特权访问管理的核心技术与实践
  • C语言实现HTTPS双向认证:从TLS原理到OpenSSL实战
  • C语言自增运算符深度解析:从原理到工程实践避坑指南
  • Cloudflare人机验证原理与网站访问优化指南
  • 新品发布:国产新型三合一多功能PG-ZYNQ7100 sbRIO板卡(PCIe+USB3.0+Ethernet+FMC+4个40pin扩展口)
  • C++ Web框架实战:从零构建高性能HTTP服务与API开发指南
  • 鸿蒙系统移植安卓设备全流程指南
  • FDE 到底是什么:为什么 AI 时代重新需要前线部署工程师(4 个标准 + 8 类风险 + 10 个问题)
  • 半导体百科:FAB设备综合效率 OEE 自动化计算与可视化看板
  • C++多线程编程:std::call_once实现线程安全一次性初始化
  • TMS320F28002x CLB模块PUSH/PULL机制:实现CPU与硬件逻辑的高效数据交换
  • 8051架构升级:金水明32051指令集设计与优化
  • Unity串口通信与传感器集成:实现智能人来人走交互系统
  • 多邻国中高级语言学习:第五阶段第13部分全攻略
  • LangGraph框架构建多智能体AI工作流实践指南
  • SpringBoot+Vue停车场系统实战:从CRUD到可维护架构的进阶之路
  • C++17 std::optional:类型安全的可选值处理与工程实践