**对比文件名称**: 3GPP TS 36.213 V12.0.0 (2013-12) “E-UTRA; Physical layer procedures”
**目标专利名称**: PUCCH资源映射和HARQ-ACK反馈
**本次调用的模型名称**: deepseek
**特征比对表格**
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **A: 一种用于由用户装备UE进行无线通信的方法** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1节 “HARQ-ACK feedback for TDD” 描述了UE在TDD模式下确定HARQ-ACK反馈的定时和资源的过程。 | 本专利要求保护一种由UE执行的方法。对比文件第10.1节通篇描述了UE在TDD模式下如何操作以进行HARQ-ACK反馈，包括确定反馈定时和PUCCH资源。虽然未明确写出“一种用于由用户装备UE进行无线通信的方法”这一主题句，但其描述的UE侧操作流程，正是本领域技术人员所理解的UE在执行无线通信（特别是HARQ-ACK反馈）时所遵循的方法。因此，该技术特征被对比文件隐含公开。 |
| **B: 接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1节。其中描述了TDD上下行配置（UL-DL configuration）是确定HARQ-ACK定时表（Table 10.1.3.1-1）的基础。结合3GPP TS 36.331中关于TDD-Config信令的描述（例如通过SIB1或专用RRC信令配置），可以确定UE需要接收指示UL-DL子帧配置的信令。 | 对比文件第10.1节明确指出，HARQ-ACK定时取决于“TDD上下行配置”（UL-DL configuration）。本领域技术人员公知，UE需要通过信令（如系统信息块SIB1或RRC重配置消息）获知其所处的TDD配置，才能进行后续的HARQ操作。虽然在本对比文件（物理层规范）中未详细描述信令的接收过程，但这是实现所述物理层过程的必要前提。因此，结合通信系统的基本原理和系列规范，该技术特征被隐含公开。 |
| **C: 基于所述动态UL‑DL子帧配置来确定混合自动重复请求HARQ确收/否定确收ACK/NACK定时** <br>**判断结果：直接公开** | 3GPP TS 36.213， 第10.1节， 及 Table 10.1.3.1-1 “ACK/NACK feedback timing for TDD”。 该表格明确列出了不同TDD UL-DL配置（Configuration 0-6）下，每个下行子帧（子帧索引 n-k， 其中 k ∈ K）对应的上行ACK/NACK反馈子帧（子帧 n）。 | 对比文件直接公开了基于TDD UL-DL子帧配置来确定HARQ ACK/NACK定时。Table 10.1.3.1-1 是一个明确的映射表，定义了对于给定的TDD配置，在每个下行子帧上接收PDSCH后，应在哪个上行子帧上进行HARQ-ACK反馈。这正是“基于UL-DL子帧配置确定HARQ ACK/NACK定时”的直接体现。其在对比文件中的作用与在目标专利中的作用完全相同，即确定反馈的时间关系。 |
| **D: 基于所述动态UL‑DL子帧配置来确定针对物理上行链路控制信道PUCCH的HARQ资源分配** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1.2.2节 “HARQ-ACK resource for TDD”。其中描述了对于TDD，用于PUCCH格式1a/1b的HARQ-ACK资源由公式 `n_{PUCCH}^{(1)} = (M - i - 1) * N_c + i * N_{c+1} + n_{CCE} + N_{PUCCH}^{(1)}` 确定，其中 `M` 是集合大小，`i` 是下行关联集索引。集合 `K`（定义了下行关联集）的大小 `M` 直接取决于TDD UL-DL配置（参见 Table 10.1.3.1-1）。 | 对比文件明确给出了TDD模式下PUCCH HARQ-ACK资源的确定公式。该公式的核心参数之一是下行关联集的大小 `M`，而 `M` 的值直接由TDD UL-DL配置决定（如Table 10.1.3.1-1所示，不同配置的K集合大小不同）。因此，确定PUCCH资源分配的过程，本质上是基于UL-DL子帧配置（通过决定M）来进行的。本领域技术人员可以直接从对比文件中确定此技术特征。虽然未使用“动态”一词，但确定资源所依赖的配置是可变的，其原理一致。 |
| **E: 以及基于所确定的HARQ资源分配和HARQ ACK/NACK定时来在所述PUCCH上传送HARQ ACK/NACK** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1节整体描述了HARQ-ACK反馈过程。确定了定时（在哪个子帧发）和资源（使用哪个PUCCH资源）后，UE在对应的上行子帧上使用分配的资源发送ACK/NACK，这是该过程的必然结果和默认执行步骤。 | 在对比文件描述的HARQ-ACK反馈方案中，确定定时和资源的最终目的就是为了在上行链路上进行传输。虽然第10.1节可能没有一句原文写明“然后UE发送”，但根据通信协议的基本逻辑和本领域技术人员的普遍理解，在确定了发送时刻和所用信道资源后，执行发送动作是隐含的、必然的后续步骤。因此，该技术特征被对比文件隐含公开。 |
| **F: 基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定HARQ‑ACK码本大小。** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1节。对于TDD，需要在一个上行子帧中反馈多个下行子帧的ACK/NACK，这构成了一个ACK/NACK码本。码本大小（即需要反馈的ACK/NACK比特数）直接取决于需要绑定的下行子帧数量，而这个数量由下行关联集 `K` 的大小 `M` 决定，`M` 又取决于TDD UL-DL配置。 | 对比文件虽然没有直接使用“码本大小”这一术语，但明确描述了TDD下的ACK/NACK绑定（bundling）和复用（multiplexing）操作。这些操作的前提是需要知道有多少个下行子帧（M个）的ACK/NACK需要被处理。这个数量M即是码本大小的决定因素。因此，基于UL-DL配置确定M，就等于基于UL-DL配置确定了HARQ-ACK码本大小。该特征被隐含公开。 |
| **G: 所述码本大小或ACK/NACK位的数目中的至少一者基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。** <br>**判断结果：直接公开** | 3GPP TS 36.213， 第10.1节及 Table 10.1.3.1-1。 Table 10.1.3.1-1 为每个TDD UL-DL配置定义了其对应的下行关联集 `K`，`K` 集合中的元素个数即为 `M`（DL关联集的大小）。需要反馈的ACK/NACK信息正是针对这 `M` 个子帧。 | 对比文件直接且明确地公开了该技术特征。Table 10.1.3.1-1 将每个TDD配置与一个特定的下行关联集 `K`（及其大小 `M`）绑定。ACK/NACK位的数目（例如，对于PUCCH格式1b with channel selection，需要反馈的比特数由M决定）正是基于这个 `M` 来确定的。这在对比文件中的作用与在目标专利中为解决“确定反馈内容量”这一技术问题的作用相同。 |
| **H: 基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定物理上行链路控制信道PUCCH资源分配。** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1.2.2节 “HARQ-ACK resource for TDD”。 如特征D所述，PUCCH资源分配公式中的关键参数 `M` 和下行子帧索引 `i` 的排序，均由TDD UL-DL配置通过定义下行关联集 `K` 来决定。 | 该技术特征与特征D和F紧密相关。对比文件第10.1.2.2节给出的资源分配公式，其计算过程直接依赖于由TDD配置决定的 `M` 和子帧打包次序。因此，确定PUCCH资源分配是包含在基于TDD配置确定HARQ资源分配的过程之中的。虽然未明确写出“包括”关系，但根据技术内容的逻辑，这是隐含的。 |
| **I: 所述物理上行链路控制信道PUCCH资源分配基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。** <br>**判断结果：直接公开** | 3GPP TS 36.213， 第10.1.2.2节及公式。 PUCCH资源 `n_{PUCCH}^{(1)}` 的计算公式为 `n_{PUCCH}^{(1)} = (M - i - 1) * N_c + i * N_{c+1} + n_{CCE} + N_{PUCCH}^{(1)}`。公式中明确包含 `M`，即DL关联集的大小。 | 对比文件直接公开了PUCCH资源分配基于DL关联集大小 `M` 来确定。资源计算公式中 `M` 是一个核心变量，直接影响资源索引的计算结果。`M` 的值来源于TDD配置（Table 10.1.3.1-1），因此该技术特征被直接公开。其作用与目标专利中相同，都是用于计算具体的物理资源位置。 |
| **J: 当确定所述DL关联集的所述大小时，集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 目标专利说明书[0169]段明确指出，本专利的“混合”设计的关键创新点之一在于：基于动态配置确定DL关联集大小时，只计数实际被配置为DL的子帧，灵活子帧若未被配置为DL则不计入。对比文件（3GPP TS 36.213 V12.0.0）描述的是静态或半静态TDD配置下的行为，其下行关联集 `K` 是预定义且固定的（如Table 10.1.3.1-1），不存在“灵活子帧动态配置为UL而不计入”的概念。这是目标专利针对eIMTA动态场景提出的特定方案，未被对比文件公开。 |
| **K: 包括通过移除UL子帧来确定所述集束集合中的剩余DL子帧的打包次序。** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1.2.2节。 资源分配公式中的索引 `i` (0 ≤ i ≤ M-1) 对应下行关联集 `K` 中的第 `i` 个元素。`K` 集合本身（如 Table 10.1.3.1-1 所列）就是从一个帧结构中筛选出的、需要反馈ACK/NACK的下行子帧的集合，它天然地“移除”了其中的上行子帧和特殊子帧，并按照 `k` 值降序排列形成了打包次序。 | 对比文件中的下行关联集 `K` 的定义，已经完成了“移除UL子帧，确定剩余DL子帧集合”的操作。例如，对于TDD配置1，其 `K` 集合为 {7, 6, 11}，这正是在一个帧中，剔除上行子帧（如子帧2,3,4,7,8,9中的上行部分）后，剩余的需要反馈的下行子帧的集合及其次序。因此，该技术特征被对比文件隐含公开。 |
| **L: 其中，固定DL子帧在所述剩余DL子帧的打包次序中被映射为第一个。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 目标专利说明书[0169]段提及“固定DL子帧始终被映射为第一个”作为一种可能的重新排序规则，旨在优化与旧式UE的资源共享。对比文件中下行关联集 `K` 的排序是严格按照 `k` 值（下行子帧与上行反馈子帧的间隔）降序排列的（参见Table 10.1.3.1-1的注释），并未引入“固定DL子帧”优先于“灵活DL子帧”的特定排序规则。此特征涉及eIMTA场景下的特定优化，未被对比文件公开。 |
| **M: 为能够支持动态UL‑DL子帧配置的UE和不能够支持动态UL‑DL子帧配置的UE配置分开的PUCCH区域。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 该特征涉及解决eIMTA UE与旧式UE之间潜在资源冲突的配置方案。对比文件（TS 36.213 V12.0.0）描述的是统一的TDD操作，所有UE遵循相同的配置和资源分配规则，没有区分支持或不支持动态配置的UE，也没有描述为它们配置分开的PUCCH区域（例如通过不同的 `N_{PUCCH}^{(1)}` 偏移）。这是目标专利提出的具体冲突避免手段，未被对比文件公开。 |
| **N: 包括确定针对能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域与针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域之间是否存在潜在冲突。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 该特征是特征M的后续动作，同样是针对eIMTA引入的动态配置场景下产生的新问题（资源冲突）而提出的解决方案。对比文件未涉及动态配置场景，因此不存在两类UE，更不存在需要判断这两类UE资源区域之间冲突的问题。此特征未被公开。 |
| **O: 若没有检测到潜在冲突，则使用针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 该特征是特征N的后续分支步骤，是具体的资源选择策略。其前提（动态配置场景、两类UE、冲突判断）均未在对比文件中公开，因此该具体的资源回用策略也未被公开。 |
| **P: 若没有检测到潜在冲突，则为第一偏移值；以及若检测到潜在冲突，则为第二偏移值。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 该特征是通过动态选择不同的PUCCH资源偏移值（`N_{PUCCH}^{(1)}`）来避免冲突的另一种方案。对比文件中的 `N_{PUCCH}^{(1)}` 是由高层配置的一个固定值。对比文件未描述根据“是否检测到冲突”这一条件来动态选择不同偏移值的机制。此特征未被公开。 |
| **Q: 指示动态上行链路‑下行链路UL‑DL子帧配置的所述信令包括动态信令。** <br>**判断结果：隐含公开** | 3GPP TS 36.213， 第10.1节提及的TDD配置，结合3GPP体系，其可以通过RRC信令（半静态）或未来可能定义的更快速的信令配置。术语“动态”在目标专利中强调其可快速改变的特性。对比文件本身未限定配置信令的时延特性，但本领域技术人员知晓配置是可以被改变的。 | 对比文件明确了HARQ过程依赖于TDD UL-DL配置。虽然V12.0.0版本可能未规范极快速的动态信令（如基于PDCCH），但“信令”本身包括多种形式。从广义上讲，任何能够传递配置信息的信令（包括RRC信令）都可以视为一种“动态信令”，因为它能够改变UE的行为配置。因此，该特征被宽松地认为是隐含公开。但需注意，目标专利中“动态”可能特指更快速（如L1）的信令，这与对比文件有区别。 |
| **R: 所述动态信令经由以下至少一者来传达：用于发射功率控制TPC命令的下行链路控制信息DCI格式中的一个或多个位，或者一个或多个确收资源偏移ARO位。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 该特征限定了非常具体的动态信令承载方式：复用DCI中的TPC命令位或ARO位来指示动态UL-DL配置或相关的资源偏移。对比文件（TS 36.213 V12.0.0）中，TPC命令位用于功率控制，ARO位用于PUCCH资源调整（例如在载波聚合中），但没有任何记载表明这些位被重新解释或用于传达动态TDD子帧配置。这是目标专利提出的特定信令设计，未被对比文件公开。 |
| **S: 检测丢失的动态UL‑DL子帧配置；以及响应于所述检测，基于系统信息块SIB中信令通知的UL‑DL子帧配置来确定HARQ资源分配。** <br>**判断结果：未公开** | （未在对比文件中找到对应描述） | 该特征涉及动态配置场景下的回退（fallback）机制。对比文件描述的是在已知且有效的TDD配置下进行操作，未涉及“动态配置丢失”这一错误或异常场景，也未定义在此场景下UE应回退到SIB1中的配置进行操作。这是目标专利为保证鲁棒性而提出的特定安全机制，未被对比文件公开。 |
<<<C>>><<<G>>><<<I>>>