**对比文件名称**：发明申请_WO2012106840A1 RESOURCE ALLOCATION FOR FLEXIBLE TDD CONFIGURATION
**目标专利名称**：PUCCH资源映射和HARQ‑ACK反馈
**本次调用模型名称**：DeepSeek最新版本模型
**特征比对表格**
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A**：一种用于由用户装备UE进行无线通信的方法 <br> **判断结果**：直接公开 | [0013]段：“……一种装置……至少：确定用于帧中子帧的第一上行链路-下行链路配置和用于帧中子帧的第二上行链路-下行链路配置，其中所述第二上行链路-下行链路配置是半静态分配的；以及当为被动态分配了上行链路-下行链路配置的第一用户装备映射自动重复请求信令时，排除由所述第二上行链路-下行链路配置映射的至少一些下行链路子帧。” <br> [0014]段：“……一种方法……确定用于帧中子帧的第一上行链路-下行链路配置和用于帧中子帧的第二上行链路-下行链路配置，其中所述第二上行链路-下行链路配置是半静态分配的；以及当为被动态分配了上行链路-下行链路配置的第一用户装备映射自动重复请求信令时，排除由所述第二上行链路-下行链路配置映射的至少一些下行链路子帧。” | 对比文件[0013]、[0014]段明确公开了一种由UE（用户装备）执行的方法，该方法包括确定配置和映射ARQ（自动重复请求，即HARQ）信令。这与目标专利权利要求中限定的“用于由用户装备UE进行无线通信的方法”在类型上完全相同。因此，技术特征A被对比文件直接公开。 |
| **技术特征B**：接收指示动态上行链路‑下行链路UL‑DL子帧配置的信令 <br> **判断结果**：直接公开 | [0006]段：“……以及如果UE没有正确检测到指示其新的灵活TDD配置的信令，也可能出现[理解不同]。” <br> [0032]段：“……第一UL-DL配置用于映射HARQ信令……” <br> [0034]段：“……对于情况2，HARQ定时的映射取决于动态分配给第一UE的灵活TDD UL-DL配置……” <br> [0036]段：“……在情况1下……ACK/NACK反馈被限制在固定UL子帧……” <br> [0052]段：“……在情况2下……ACK/NACK反馈不限于固定UL子帧，因为第一UL-DL配置本身是动态分配给第一/新UE的。” | 对比文件通篇描述了“灵活TDD配置”（即动态UL-DL子帧配置）的概念，并明确指出UE需要接收指示该配置的信令（[0006]段），且该信令用于确定HARQ信令的映射（[0032], [0034], [0036], [0052]段）。这与目标专利中“接收指示动态UL-DL子帧配置的信令”的技术特征在内容和作用上均相同，都是使UE获知当前使用的动态配置。因此，技术特征B被对比文件直接公开。 |
| **技术特征C**：基于所述动态UL‑DL子帧配置来确定混合自动重复请求HARQ确收/否定确收ACK/NACK定时 <br> **判断结果**：隐含公开 | [0030]段：“情况1涉及的一般方法是，新UE（支持灵活UL-DL配置）的ACK/NACK反馈被限制为遵循为现有TDD UL-DL配置#2（或替代地TDD UL-DL配置#5）规定的ACK/NACK反馈定时。这意味着无论为新UE灵活配置的UL-DL是什么，ACK/NACK反馈映射都是使用UL-DL配置#2完成的。” <br> [0031]段：“情况2涉及的一般方法是，新UE（支持灵活UL-DL配置）的ACK/NACK反馈遵循灵活配置的UL-DL配置的确切模式。” <br> [0034]段：“对于情况1，HARQ定时的映射因此独立于动态分配给第一UE的灵活TDD UL-DL配置……对于情况2，HARQ定时的映射取决于动态分配给第一UE的灵活TDD UL-DL配置……” | 目标专利说明书中明确说明（如[0154]段），其“混合”设计的核心之一是**基于参考UL-DL子帧配置**确定HARQ ACK/NACK定时，而非基于动态配置。技术特征C要求“基于动态配置确定定时”，这与目标专利自身的方案相悖，可能为撰写瑕疵。对比文件提出了两种方案：情况1（定时基于固定参考配置）和情况2（定时基于动态配置）。对比文件直接公开了情况1，但未直接公开情况2的定时确定具体步骤。然而，本领域技术人员从[0031]、[0034]段关于情况2的描述（ACK/NACK反馈遵循灵活配置的确切模式，HARQ定时取决于动态配置）可以合理推断出，要实现“遵循灵活配置的确切模式”，必然需要基于该动态配置来确定ACK/NACK与DL子帧之间的定时关系（即k值集合，如背景技术[0007]段所述）。因此，技术特征C被对比文件隐含公开。 |
| **技术特征D**：基于所述动态UL‑DL子帧配置来确定针对物理上行链路控制信道PUCCH的HARQ资源分配 <br> **判断结果**：直接公开 | [0036]段：“……图3示例中，PUCCH资源映射隐含在动态向第一UE分配UL-DL配置的信令中。” <br> [0048]段：“……对于图4的第二实施例，存在隐式和显式混合的PUCCH分配。” <br> [0052]段：“……在图5示例中，PUCCH资源映射隐含在动态向第一UE分配UL-DL配置的信令中。” <br> [0062]段：“……对于此第四实施例，第二组内的DL子帧的PUCCH资源由eNB通过某种显式信令传达。” <br> [0068]段：“……对于第二组中的DL子帧，PUCCH资源可以基于隐式CCE到PUCCH映射……或者PUCCH资源可以由eNB在第二和第四实施例中通过信令显式分配。” | 对比文件多个实施例（第一、三实施例为隐式映射，第二、四实施例为显式信令）的核心内容都是为支持灵活TDD的UE确定PUCCH资源分配，并且该分配过程与动态配置（第一配置）紧密相关。例如，在情况2（[0052]段）下，资源分配直接基于动态配置；在情况1（[0036]段）下，虽然定时固定，但资源分组和索引仍考虑了动态配置的影响以避免冲突。这实质上是“基于动态配置来确定PUCCH的HARQ资源分配”。因此，技术特征D被对比文件直接公开。 |
| **技术特征E**：以及基于所确定的HARQ资源分配和HARQ ACK/NACK定时来在所述PUCCH上传送HARQ ACK/NACK <br> **判断结果**：直接公开 | [0007]段：“具体对于LTE，UE在UL子帧n中发送其针对DL子帧n-k的ACK/NACK……” <br> [0030]段：“情况1涉及的一般方法是，新UE（支持灵活UL-DL配置）的ACK/NACK反馈被限制为遵循为现有TDD UL-DL配置#2（或替代地TDD UL-DL配置#5）规定的ACK/NACK反馈定时。” <br> [0046]段：“第一/新UE根据上述第二组中的DL子帧映射到适当的UL子帧n_pucch……网络类似地但反向地映射，从它接收到ACK/NACK的UL子帧到与该ACK/NACK相关联的DL子帧，以知道网络发送的哪个数据被ACK/NACK。” | 对比文件明确描述了UE在UL子帧中发送ACK/NACK反馈的完整过程：先确定定时（在哪个UL子帧发送）和资源（使用哪个PUCCH资源），然后进行发送。例如，[0007]段描述了基本定时关系，[0030]段描述了情况1下的定时，[0046]段描述了映射后发送的过程。这直接公开了“基于确定的定时和资源分配来在PUCCH上传送HARQ ACK/NACK”这一技术特征。因此，技术特征E被对比文件直接公开。 |
| **技术特征F**：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定HARQ‑ACK码本大小。 <br> **判断结果**：隐含公开 | [0007]段：“在当前LTE规范中，PUCCH ACK/NACK资源被定义为M的函数，M是如图1和上文所示的DL关联集的大小。” <br> [0035]段：“在以下各种PUCCH资源分配方案的示例中，假设第一（新）UE配置有ACK/NACK捆绑或ACK/NACK复用，且M=1，其中M是DL关联集的大小。此假设并非限制，这些示例可以很容易地扩展到使用M大于1的ACK/NACK复用的情况。” <br> [0054]段：“首先，定义两个DL子帧/特殊子帧组如下，假设UL子帧n是发送映射的ACK/NACK的子帧……第二组包含根据第一/灵活UL-DL配置对应于UL子帧的DL关联集中的DL子帧，但不包括在第一组中的子帧。” | 目标专利中“HARQ-ACK码本大小”指需要反馈的ACK/NACK比特数，其与DL关联集大小M直接相关（见说明书[0161]段）。对比文件虽然没有直接使用“码本大小”这一术语，但明确指出PUCCH资源是DL关联集大小M的函数（[0007]段），并且在描述资源分配方案时，核心步骤之一就是确定属于新UE的DL子帧组（即有效的DL关联集，如[0054]段），这直接决定了需要反馈的DL子帧数量。本领域技术人员知晓，需要反馈的DL子帧数量（即M）直接决定了ACK/NACK码本的大小。因此，基于动态UL-DL配置来确定哪些DL子帧需要反馈（即确定M），实质上就是基于动态配置来确定HARQ-ACK码本大小。因此，技术特征F被对比文件隐含公开。 |
| **技术特征G**：所述码本大小或ACK/NACK位的数目中的至少一者基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。 <br> **判断结果**：隐含公开 | [0007]段：“在当前LTE规范中，PUCCH ACK/NACK资源被定义为M的函数，M是如图1和上文所示的DL关联集的大小。” <br> [0035]段：“……假设第一（新）UE配置有ACK/NACK捆绑或ACK/NACK复用，且M=1，其中M是DL关联集的大小。” <br> [0054]段：“第二组包含根据第一/灵活UL-DL配置对应于UL子帧的DL关联集中的DL子帧，但不包括在第一组中的子帧。” | 如特征F所述，对比文件公开了资源分配与DL关联集大小M相关，且M是根据动态配置（第一配置）确定的（[0054]段）。在LTE系统中，ACK/NACK比特数目（无论是捆绑、复用还是格式3）均由需要反馈的DL子帧数量（即M）以及传输模式、载波数等因素决定。本领域技术人员可以毫无疑义地确定，一旦根据动态配置确定了需要反馈的DL子帧集合（即DL关联集），那么ACK/NACK位的数目（即码本大小的体现）也就随之确定。因此，技术特征G被对比文件隐含公开。 |
| **技术特征H**：基于所述动态UL‑DL子帧配置来确定HARQ资源分配包括基于所述动态UL‑DL子帧配置来确定物理上行链路控制信道PUCCH资源分配。 <br> **判断结果**：直接公开 | [0036]段：“在情况1下……PUCCH资源映射隐含在动态向第一UE分配UL-DL配置的信令中。” <br> [0048]段：“……对于第二实施例……存在隐式和显式混合的PUCCH分配。” <br> [0052]段：“在情况2下……PUCCH资源映射隐含在动态向第一UE分配UL-DL配置的信令中。” <br> [0068]段：“对于第二组中的DL子帧，PUCCH资源可以基于隐式CCE到PUCCH映射……或者PUCCH资源可以由eNB……通过信令显式分配。” | 此特征与技术特征D的实质内容一致，强调“确定PUCCH资源分配”是“确定HARQ资源分配”的具体组成部分。对比文件的所有实施例（第一至第四）的核心主题就是为支持灵活TDD的UE“确定PUCCH资源分配”，并且该确定过程是基于动态配置（第一配置）进行的（[0036], [0052]段）。因此，技术特征H被对比文件直接公开。 |
| **技术特征I**：所述物理上行链路控制信道PUCCH资源分配基于所述动态UL‑DL子帧配置的DL关联集的大小来确定。 <br> **判断结果**：直接公开 | [0007]段：“在当前LTE规范中，PUCCH ACK/NACK资源被定义为M的函数，M是如图1和上文所示的DL关联集的大小。” <br> [0038]-[0041]段：“首先，基于常规分配（图1）确定DL关联集……第三，第一组子帧的PUCCH资源按照与第二/初始TDD配置相同的方式首先建立索引……第四，第二组子帧的PUCCH资源通过以下方式建立索引……”（具体公式涉及Ncce等参数，其计算依赖于分组内子帧数量） <br> [0054]-[0056]段：“首先，定义两个DL子帧组……第二组形成DL关联集C，其PUCCH资源索引如下：……其中Mc是第二组中DL子帧的数量……” | 对比文件[0007]段明确了PUCCH资源是DL关联集大小M的函数。在具体实施例中（如[0038]-[0041]段，[0054]-[0056]段），详细描述了如何根据动态配置（第一配置）和初始配置（第二配置）划分出实际用于新UE反馈的DL子帧组（即有效的DL关联集），并基于该组内子帧的数量（Mc等）和CCE索引来计算具体的PUCCH资源索引（n_pucch）。这直接公开了“PUCCH资源分配基于动态配置的DL关联集大小来确定”这一技术特征。因此，技术特征I被对比文件直接公开。 |
| **技术特征J**：当确定所述DL关联集的所述大小时，集束集合中未被配置为所述动态UL‑DL配置中的DL的灵活子帧不被计及。 <br> **判断结果**：直接公开 | [0039]段：“第二，将集合A内的DL子帧分为两组。第一组包含集合B中的DL子帧/特殊子帧，这是由第二/初始TDD配置确定的DL关联集。第二组包含集合A中所有其他的DL子帧。” <br> [0054]段：“第二组包含根据第一/灵活UL-DL配置对应于UL子帧的DL关联集中的DL子帧，但不在第一组中的子帧。” <br> [0027]段：“首先，考虑到复杂性和灵活性之间的平衡，TDD子帧可以分为固定子帧和动态/灵活子帧。” | 对比文件的核心方案就是将需要反馈的DL子帧分为两组。第一组是根据初始配置（针对旧式UE）确定的DL关联集。第二组是根据动态配置（第一配置）确定的DL关联集**排除掉第一组之后剩余的子帧**（[0039]，[0054]段）。这意味着，在为新UE确定有效的DL关联集（即计算其大小时），那些虽然属于动态配置的DL关联集，但已被初始配置占用的子帧（即未被动态配置实际用于新UEDL传输的“灵活子帧”，在冲突避免的意义上）不被计入新UE的反馈集合。这直接对应于目标专利的“集束集合中未被配置为动态UL-DL配置中的DL的灵活子帧不被计及”。因此，技术特征J被对比文件直接公开。 |
| **技术特征K**：包括通过移除UL子帧来确定所述集束集合中的剩余DL子帧的打包次序。 <br> **判断结果**：直接公开 | [0039]段：“……第二组包含集合A中所有其他的DL子帧。” <br> [0043]段：“……对于第二组中的固定DL子帧，它们的CCE在映射到其PUCCH资源之前也如常规方式一样进行交织。第二组中固定子帧的CCE交织以与常规方式相同的方式进行……，但删除了第一组中的DL子帧和灵活子帧的CCE。” <br> [0059]段：“所有其他根据第一/灵活TDD配置需要在同一UL子帧n中反馈的DL子帧/特殊子帧形成第二组。……第二组中的子帧的交织以常规方式进行……，但删除了第一组的DL子帧。” | 对比文件在描述PUCCH资源索引计算时，明确提到了“交织（interleaving）”和“索引（indexing）”步骤。这实质上就是确定DL子帧的CCE映射到PUCCH资源序列时的“打包次序”。对比文件指出，在为新UE（第二组子帧）进行交织/索引时，需要**删除（remove）或排除（exclude）** 第一组（即旧式UE使用的）子帧的CCE（[0043]，[0059]段）。由于第一组子帧对应的是初始配置的DL关联集，而初始配置中某些子帧在动态配置下可能是UL子帧，因此“删除第一组子帧”这一操作，在效果上等同于“通过移除UL子帧来确定剩余DL子帧的打包次序”。因此，技术特征K被对比文件直接公开。 |
| **技术特征L**：其中，固定DL子帧在所述剩余DL子帧的打包次序中被映射为第一个。 <br> **判断结果**：直接公开 | [0039]段：“……其中{n-13, n-12, n-5, n-4}是固定DL子帧并首先索引，随后是灵活子帧{n-8, n-9}。” <br> [0041]段：“i. 第二组中的固定DL子帧形成DL关联集C，它们的PUCCH资源由以下公式确定：…… ii. 灵活子帧4或9的PUCCH（如果可用）索引如下…… iii. 灵活子帧3或8的PUCCH（如果可用）索引如下……” <br> [0044]段：“如果第二组中有多个灵活DL子帧，则首先索引灵活子帧n-4和/或n-9的PUCCH资源，然后索引灵活子帧n-3和/或n-8的PUCCH资源。” | 对比文件在[0039]段明确教导，在第二组（即新UE的剩余DL子帧）中，**固定DL子帧首先被索引**，然后才索引灵活子帧。在[0041]段和[0044]段进一步细化了索引顺序：先处理固定DL子帧，然后在灵活子帧中，又按特定顺序（如子帧4/9先于3/8）索引。这直接公开了“固定DL子帧在剩余DL子帧的打包次序中被映射为第一个”这一具体规则。因此，技术特征L被对比文件直接公开。 |
| **技术特征M**：为能够支持动态UL‑DL子帧配置的UE和不能够支持动态UL‑DL子帧配置的UE配置分开的PUCCH区域。 <br> **判断结果**：直接公开 | [0012]段：“……为Release 11 UE配置不同的PUCCH资源偏移以避免此类冲突是低效的，因为PUCCH区域中Release 11与旧式UE之间的复用是不可能的。” <br> [0042]段：“……第一组……它们的CCE以与第二/初始TDD配置相同的方式交织和索引，就像用于映射到其PUCCH资源的Release 10常规方式一样。这使其与旧式UE的操作向后兼容。” <br> [0051]段：“第一组DL子帧的PUCCH资源通过隐式映射确定，如Release 10中第二/初始TDD配置的常规方式，而第二组DL子帧的PUCCH资源被显式信令通知。” | 对比文件[0012]段提到了为不同UE配置不同PUCCH资源偏移的概念。[0042]段和[0051]段则清晰表明，其整个方案的设计目的就是实现新旧UE的共存：旧式UE使用基于初始配置的隐式映射资源（第一组），而新UE使用基于新规则（排除第一组后）确定的资源（第二组），这些资源要么通过修改的隐式规则计算，要么通过显式信令分配。这实质上就是为两类UE配置了分开的、互不冲突的PUCCH资源区域。因此，技术特征M被对比文件直接公开。 |
| **技术特征N**：包括确定针对能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域与针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域之间是否存在潜在冲突。 <br> **判断结果**：直接公开 | [0009]段：“……如果对TDD配置有不同的理解，无论是在不同UE之间还是在UE与eNB之间，显然都可能发生PUCCH资源冲突或eNB处的检测错误。” <br> [0010]-[0011]段：“图2A-B说明了PUCCH资源冲突问题……这是一个PUCCH冲突。” <br> [0012]段：“发明人认为，对此冲突的两个直接解决方案是次优的。” | 对比文件开篇即用大量篇幅（[0009]-[0012]段）描述并图示了新旧UE之间因配置不同导致的PUCCH资源碰撞问题。整个发明所要解决的核心技术问题就是识别并避免这种“潜在冲突”。因此，“确定潜在冲突是否存在”是对比文件方案实施的前提和要解决的问题本身，已被对比文件直接公开。因此，技术特征N被对比文件直接公开。 |
| **技术特征O**：若没有检测到潜在冲突，则使用针对不能够支持动态UL‑DL子帧配置的UE的所述PUCCH区域。 <br> **判断结果**：直接公开 | [0042]段：“第一组由根据系统信息中指示的第二/初始TDD配置需要在同一UL子帧n中反馈的DL子帧/特殊子帧组成。对于此组中的DL子帧，它们的CCE以与第二/初始TDD配置相同的方式交织和索引，就像用于映射到其PUCCH资源的Release 10常规方式一样。**这使其与旧式UE的操作向后兼容。**” | 对比文件方案中，第一组子帧的资源分配完全遵循旧式UE（即不支持动态配置的UE）的常规规则（[0042]段）。这意味着，对于第一组内的子帧，新UE和旧式UE使用的是**相同的、共享的PUCCH区域**。只有当动态配置引入额外需要反馈的子帧（第二组）时，才需要分配额外或分开的资源。因此，在“没有检测到潜在冲突”的场合（即第一组子帧的反馈），新UE就是直接使用旧式UE的PUCCH区域。这直接公开了技术特征O。因此，技术特征O被对比文件直接公开。 |
| **技术特征P**：若没有检测到潜在冲突，则为第一偏移值；以及若检测到潜在冲突，则为第二偏移值。 <br> **判断结果**：隐含公开 | [0009]段：“n_pucch = CCE_index + N^(1)_pucch，其中……N^(1)_pucch由高层配置。” <br> [0012]段：“……为Release 11 UE配置不同的PUCCH资源偏移（N^(1)_pucch）以避免此类冲突是高度低效的……” <br> 对比文件整体方案 | 对比文件[0009]段给出了常规PUCCH资源计算公式，其中包含一个由高层配置的偏移值N^(1)_pucch。[0012]段指出，简单地给新UE配置一个不同的N^(1)_pucch值来避免冲突是低效的。对比文件提出的完整方案（分组、排除、重新索引）是一种更优雅的冲突解决方案。本领域技术人员可以理解，该方案等效于一种动态的偏移调整策略：对于与旧式UE无冲突的反馈（即第一组子帧），使用常规偏移（第一偏移值）；对于可能冲突的反馈（即第二组子帧），通过新的索引计算规则或显式信令，等效于应用了一个不同的偏移（第二偏移值）来将资源定位到不同的区域。因此，技术特征P所描述的冲突处理逻辑，被对比文件的整体方案所隐含公开。 |
| **技术特征Q**：指示动态上行链路‑下行链路UL‑DL子帧配置的所述信令包括动态信令。 <br> **判断结果**：直接公开 | [0006]段：“……如果UE没有正确检测到指示其新的灵活TDD配置的信令，也可能出现[理解不同]。” <br> [0032]段：“……第一UL-DL配置用于映射HARQ信令……” <br> [0050]段：“……然后网络动态地向第一/新UE指示……” <br> [0066]段：“……然后UE通过第1层（L1）信令被发送一个指示……” | 对比文件多次提及用于指示灵活（动态）TDD配置的“信令”（[0006]段），并明确提到了“动态指示”（[0050]段）和“L1信令”（[0066]段）。L1信令（如PDCCH中的DCI）是典型的动态信令。这直接公开了“指示动态UL-DL子帧配置的信令包括动态信令”。因此，技术特征Q被对比文件直接公开。 |
| **技术特征R**：所述动态信令经由以下至少一者来传达：用于发射功率控制TPC命令的下行链路控制信息DCI格式中的一个或多个位，或者一个或多个确收资源偏移ARO位。 <br> **判断结果**：隐含公开 | [0066]段：“……例如，包含DL授权的PDCCH中的两个位可以指示四组PUCCH资源中的一组。” <br> 对比文件整体关于显式信令分配的教导（如第二、四实施例） | 对比文件[0066]段例举了使用PDCCH中的位（即DCI格式中的位）来动态指示PUCCH资源组。虽然未明确提及这些位是“TPC命令位”或“ARO位”，但本领域技术人员知晓，在LTE中，DCI格式中的某些字段（如TPC命令）可以被重用来传递其他信息，ARO也是DCI中已定义的字段。对比文件教导了使用DCI中的位进行动态资源指示，这隐含涵盖了使用DCI中现有字段（如TPC或ARO）或新定义字段来实现该功能的可能性。因此，技术特征R被对比文件隐含公开。 |
| **技术特征S**：检测丢失的动态UL‑DL子帧配置；以及响应于所述检测，基于系统信息块SIB中信令通知的UL‑DL子帧配置来确定HARQ资源分配。 <br> **判断结果**：直接公开 | [0006]段：“……如果UE没有正确检测到指示其新的灵活TDD配置的信令，也可能出现[理解不同]。” <br> [0028]段：“由于信令错误导致的冲突可以通过将ACK/NACK反馈限制在固定子帧中来避免，从而使反馈映射独立于Release 11（灵活TDD分配）UE的TDD配置。这样做的代价是HARQ反馈信令的延迟略有增加。” <br> [0032]段：“……假设存在一个初始TDD配置，即在系统信息中广播的TDD UL-DL配置，并且由小区中的旧式UE常规使用。” | 对比文件[0006]段明确提出了UE可能未正确检测到动态配置信令的问题。[0028]段提出了解决方案：将反馈限制在固定子帧，使其独立于灵活配置。结合[0032]段，该“固定子帧”的确定依据就是系统广播的“初始TDD配置”。这直接对应于目标专利的回退机制：当动态配置信令丢失时，UE回退到使用系统信息块（SIB）中广播的配置来确定HARQ资源分配（此时资源分配基于初始配置，而非动态配置）。因此，技术特征S被对比文件直接公开。 |
<<<A>>><<<B>>><<<D>>><<<E>>><<<H>>><<<I>>><<<J>>><<<K>>><<<L>>><<<M>>><<<N>>><<<O>>><<<Q>>><<<S>>>
<<<c>>><<<f>>><<<g>>><<<p>>><<<r>>>