**对比文件名称**：2013-09-19_US2013242819A_发明申请_US20130242819A1 SCHEDULING TIMING DESIGN FOR A TDD SYSTEM
**目标专利名称**：252具有动态TDD DL_UL子帧配置的载波聚合CN105940631B
**本次调用模型名称**：GPT-4
以下是根据目标专利权利要求的技术特征划分，与对比文件进行比对的结果：
### **特征比对表格**
| 技术特征描述及公开性判断 | 对比文件原文引用（段落号/位置） | 公开性论述 |
| **特征A：接收包括至少第一分量载波(CC)和第二CC的配置，所述第一CC或所述第二CC中的至少一个CC被启用用于针对业务适应的演进型干扰管理(eIMTA)** <br>**《未公开》** | 未发现直接相关描述。对比文件讨论了具有不同UL-DL子帧配置的TDD载波聚合（例如，[0037]-[0039]），但未提及“针对业务适应的演进型干扰管理(eIMTA)”或子帧配置的动态适应/启用概念。 | 在目标专利中，“被启用用于eIMTA”意味着CC支持TDD DL/UL子帧配置的动态、基于业务的自适应（见说明书[0003], [0006], [0009]）。对比文件（基于其背景[0003]和实施例）仅涉及不同但固定的（半静态）TDD UL-DL子帧配置的聚合，以提高资源效率，未涉及子帧配置的动态重配置或eIMTA机制。因此，对比文件未公开或隐含公开“CC被启用用于eIMTA”这一技术特征。 |
| **特征B：确定用于所述第一CC和所述第二CC中的至少一个CC的混合自动重传请求(HARQ)时序** <br>**《直接公开》** | [0033]：“Processor module 152 may use HARQ module 158 to select HARQ timing sequence or timing schedules based on one of the UL-DL subframe configurations of PCell or SCell.” <br>[0043]：“...the scheduling timing of the HARQ process may follow the UL-DL subframe configuration of the scheduling cell at 420. Alternatively... may follow the UL-DL subframe configuration of the scheduled cell at 425.” | 对比文件明确公开了在载波聚合场景下，为调度小区（scheduling cell，可对应一个CC）和被调度小区（scheduled cell，可对应另一个CC）确定HARQ时序（timing sequence/schedule）的方法。这与目标专利中“确定用于至少一个CC的HARQ时序”的技术特征相同。 |
| **特征C：所确定的HARQ时序是至少部分地基于所接收到的配置以及所述第一CC或所述第二CC中的所述至少一个CC被启用用于eIMTA的** <br>**《未公开》** | 未发现直接相关描述。对比文件中确定HARQ时序的决策依据是调度小区/被调度小区的UL-DL配置类型（Type1/Type2）或通过查表确定参考配置（[0040]-[0063]），未涉及CC是否被“启用用于eIMTA”。 | 目标专利中，HARQ时序的确定需特别考虑CC是否支持eIMTA（动态配置），这是其解决动态配置带来的时序复杂性问题的核心（见说明书[0009], [0043]）。对比文件解决的是固定但不同配置的CC间的时序协调问题，其决策逻辑（如基于配置类型或查表）完全不依赖于“eIMTA启用”状态。因此，该特征未被公开。 |
| **特征D：所确定的HARQ时序是进一步基于以下各项的：所述第一CC和所述第二CC的交叉载波调度配置、以及使用与所述第一CC对应的第一子帧配置索引和与所述第二CC对应的第二子帧配置索引来对表进行索引** <br>**《直接公开》** | [0037]：“In embodiments where CA is used, cross-carrier scheduling may be performed.” <br>[0050]-[0054], [0057]-[0061]：描述了通过查表（例如图8、图10的表格）确定参考UL-DL子帧配置的方法，该表格的行和列分别对应调度小区（第一CC）和被调度小区（第二CC）的UL-DL配置索引（即子帧配置索引）。 | 对比文件明确公开了在交叉载波调度（cross-carrier scheduling）场景下，HARQ时序（通过参考配置体现）是基于调度小区和被调度小区的UL-DL子帧配置索引，通过查询预定表格来确定的。例如，图8和10的表格即展示了如何使用两个配置索引进行索引以得到参考配置。这与技术特征D的描述完全一致。 |
| **特征E：以及至少部分地基于所确定的HARQ时序，使用所述第一CC和所述第二CC中的所述至少一个CC进行通信。** <br>**《直接公开》** | [0033]：“Processor module 152 may be configured to use communication module 154 to transmit information in uplink subframes of the PCell, e.g., on CC_0, according to the scheduling of a first UL-DL subframe configuration...” <br>[0045]-[0048]：结合图5、6描述了根据所选的HARQ时序（遵循调度小区或被调度小区的配置）进行上行链路数据传输和ACK/NACK反馈的过程。 | 对比文件公开了在确定HARQ时序（或参考配置）后，用户设备（UE）或基站（eNB）按照此时序在相应的CC上进行通信（如UL数据传输和DL ACK/NACK反馈）。这直接对应于“基于所确定的HARQ时序...进行通信”的技术特征。 |
| **特征F：其中，确定所述HARQ时序是基于被启用用于eIMTA的所述至少一个CC的动态配置的下行链路/上行链路(DL/UL)子帧配置的。** <br>**《未公开》** | 未发现直接相关描述。对比文件中所有关于UL-DL子帧配置的引用（如SIB1指示）均为半静态配置（[0031]），未提及配置可动态改变。 | 目标专利中“动态配置的DL/UL子帧配置”是eIMTA的核心特征，配置可基于业务需求快速变化（见说明书[0006], [0079]）。对比文件全文仅讨论固定的、半静态的UL-DL子帧配置之间的协调，完全没有涉及“动态配置”。因此，该特征未被公开。 |
| **特征G：其中，确定所述HARQ时序是基于被启用用于eIMTA的所述至少一个CC的半静态下行链路/上行链路(DL/UL)子帧配置的。** <br>**《直接公开》** | [0031]：“In some embodiments, the indications of the UL-DL subframe configurations may be transmitted to the UE 108 in a control signal which may be referred to as a system information block (SIB)... specifically be the first system information block (SIB1)” <br>[0040]-[0043]：基于调度小区或被调度小区的UL-DL子帧配置（即SIB1指示的半静态配置）来确定HARQ时序。 | 对比文件公开的HARQ时序确定方法，无论是遵循调度小区还是被调度小区的配置，其依据都是通过SIB1消息广播的、半静态的UL-DL子帧配置。这直接公开了“基于半静态DL/UL子帧配置确定HARQ时序”的技术特征，尽管其上下文不涉及eIMTA。 |
| **特征H：其中，UL HARQ时序是基于在用于被启用用于eIMTA的所述至少一个CC的广播系统信息块(SIB)消息中指示的子帧配置确定的。** <br>**《直接公开》** | [0031]：“...the indications of the UL-DL subframe configurations may be transmitted to the UE 108 in a control signal which may be referred to as a system information block (SIB)... specifically be the first system information block (SIB1)” <br>[0040]-[0043], [0050]-[0054]：确定HARQ时序（特别是上行HARQ时序，如PUSCH调度和ACK反馈时序）所依据的UL-DL子帧配置正是由SIB1指示的。 | 对比文件明确公开了UL HARQ时序是基于SIB1消息中指示的（半静态）子帧配置来确定的。这与特征H的文字描述完全吻合，尽管对比文件中的CC并非“被启用用于eIMTA”。 |
| **特征I：其中，DL HARQ时序是基于由用于被启用用于eIMTA的所述至少一个CC的无线资源控制(RRC)消息指示的子帧配置确定的。** <br>**《未公开》** | 未发现相关描述。对比文件中未提及通过RRC消息专门指示用于DL HARQ时序的子帧配置。 | 目标专利说明书[0011]提及，DL HARQ时序可基于RRC消息指示的子帧配置确定，这可能与eIMTA中半静态参考配置的专用信令有关。对比文件仅使用广播的SIB1消息来传递配置信息，未公开通过RRC消息（一种专用信令）来指示用于DL HARQ时序的子帧配置。因此，该特征未被公开。 |
| **特征J：其中，所述HARQ时序包括HARQ确认(ACK)时序和HARQ调度时序中的至少一个。** <br>**《直接公开》** | [0030]：“...eNB 104 may be configured to transmit ACK or NACK signals...” <br>[0039], [0045]-[0048]：描述了PUSCH的调度传输（UL grant timing）以及对应的ACK/NACK反馈时序，这涵盖了HARQ调度时序和ACK时序。 | 对比文件涉及的HARQ时序设计，核心就是解决上行链路数据发送（与调度相关）和下行链路ACK/NACK反馈之间的时序关系。因此，其公开的“HARQ timing sequence”必然包括HARQ调度时序和HARQ ACK时序中的至少一个。 |
| **特征K：其中，所确定的HARQ时序是进一步至少部分地基于下面至少之一的：所述第一CC和所述第二CC是具有时域双工(TDD)还是频域双工(FDD)帧结构类型，所述第一CC和所述第二CC作为主CC或辅CC的指定，物理上行链路控制信道(PUCCH)的数量，或者所述第一CC和所述第二CC是针对载波聚合操作还是针对双连接操作配置的。** <br>**《未公开》** | 对比文件仅涉及TDD载波聚合（[0004], [0028]），未提及FDD帧结构类型、PUCCH数量或双连接操作。虽然提到主服务小区（PCell）和辅服务小区（SCell）（[0026]），但HARQ时序的确定规则（如基于配置类型或查表）并非直接、明确地“基于主CC或辅CC的指定”，而是基于“调度小区”和“被调度小区”的角色，该角色可能与主/辅指定有关，但对比文件未将其作为独立的决策因素进行阐述。 | 目标专利的特征K列举了多个在eIMTA场景下影响HARQ时序决策的附加因素，以处理更复杂的场景（如TDD-FDD联合、多PUCCH、双连接）。对比文件仅限于同构的TDD CA场景，其时序决策逻辑相对简单，未涉及这些扩展因素。因此，该组合特征未被公开。 |
| **特征L：其中，如果被启用用于eIMTA的所述至少一个CC是所述主CC并且所述PUCCH的数量是一，其中所述一个PUCCH是在所述主CC上的，则用于所述主CC和所述辅CC二者的所述HARQ时序是基于所述主CC的半静态DL/UL子帧配置的。** <br>**《未公开》** | 未发现相关描述。对比文件未涉及“eIMTA启用”、“PUCCH数量”等概念，也未给出基于“主CC是eIMTA启用且只有一个PUCCH在主CC上”这一具体条件来决定主辅CC均采用主CC半静态配置的规则。 | 这是目标专利中为特定eIMTA场景设计的具体规则之一（见说明书[0012]）。对比文件完全没有涉及此类具体条件判断和相应的时序绑定规则。因此，该特征未被公开。 |
| **特征M：其中，如果被启用用于eIMTA的所述至少一个CC是所述辅CC并且所述主CC是TDD帧结构类型的，则用于所述主CC和所述辅CC二者的所述HARQ时序是基于所述辅CC的半静态DL/UL子帧配置的。** <br>**《未公开》** | 未发现相关描述。对比文件未涉及“eIMTA启用”，也未给出当辅CC（对应被调度小区）具有某种属性时，主CC（对应调度小区）的HARQ时序也基于辅CC配置的规则。其规则是调度小区或被调度小区的配置可能作为参考，但并非强制将两者时序统一基于其一。 | 这是目标专利中另一条具体的eIMTA场景规则（见说明书[0012]）。对比文件的时序确定逻辑与此不同，且不依赖于“eIMTA启用”状态。因此，该特征未被公开。 |
| **特征N：其中，如果被启用用于eIMTA的所述至少一个CC是所述辅CC，并且所述主CC是FDD帧结构类型的，则用于所述辅CC的所述HARQ时序是基于所述辅CC的动态DL/UL子帧配置的。** <br>**《未公开》** | 未发现相关描述。对比文件未涉及FDD帧结构类型，也未涉及动态DL/UL子帧配置。 | 该特征涉及TDD-FDD联合操作且TDD辅CC启用eIMTA的特定场景。对比文件完全不涉及FDD、动态配置以及此特定条件组合下的规则。因此，该特征未被公开。 |
| **特征O：其中，确定所述HARQ时序包括确定用于上行链路控制信息(UCI)报告的HARQ时序，并且所述HARQ时序指示用于发送所述UCI报告的一个或多个子帧。** <br>**《未公开》** | 未发现相关描述。对比文件主要关注PUSCH数据及其ACK/NACK的HARQ时序，未提及上行链路控制信息（UCI）报告（如CQI、PMI、RI等）的专门时序确定。 | 目标专利将HARQ时序的概念扩展到UCI报告的发送时序（见说明书[0013], [0082]）。对比文件未涉及UCI报告传输的时序设计问题。因此，该特征未被公开。 |
| **特征P：还包括：基于所述UCI报告是否针对被启用用于eIMTA的所述至少一个CC或者所述UCI报告是与固定的还是动态确定的子帧相关联，划分所述UCI的发送的优先级。** <br>**《未公开》** | 未发现任何关于UCI报告优先级划分的描述。 | 目标专利中UCI发送优先级划分是为了解决在eIMTA动态子帧场景下多个UCI报告的冲突问题（见说明书[0013], [0090]）。对比文件完全没有涉及UCI报告，更未涉及基于eIMTA状态或子帧类型（固定/动态）的优先级划分机制。因此，该特征未被公开。 |
| **特征Q：其中，确定用于发送所述UCI报告的所述HARQ时序是至少部分地基于被启用用于eIMTA的所述至少一个CC是否是携带物理上行链路控制信道(PUCCH)的CC的。** <br>**《未公开》** | 未发现相关描述。对比文件虽然提到了PUCCH（[0027]），但未将其与HARQ时序确定或UCI报告发送时序关联，也未涉及“携带PUCCH的CC”是否是eIMTA启用这一判断条件。 | 这是目标专利中针对UCI报告传输设计的又一具体规则，其核心在于考虑PUCCH所在CC的eIMTA状态（见说明书[0014]）。对比文件未涉及UCI报告时序问题，故该特征未被公开。 |
| **特征R：其中，如果被启用用于eIMTA的所述至少一个CC是携带PUCCH的所述CC，则用于在被启用用于eIMTA的所述至少一个CC上发送UCI报告的所述HARQ时序使用动态确定的上行链路子帧。** <br>**《未公开》** | 未发现相关描述。对比文件未涉及UCI报告、动态确定的上行链路子帧，也未涉及“eIMTA启用的PUCCH CC”这一场景。 | 这是特征Q下的一种具体实施方式。对比文件未提供任何与此相关的技术教导。因此，该特征未被公开。 |
| **特征S：其中，如果被启用用于eIMTA的所述至少一个CC不是携带PUCCH的所述CC，则用于在携带所述PUCCH的所述CC上发送UCI报告的所述HARQ时序使用固定的上行链路子帧。** <br>**《未公开》** | 未发现相关描述。对比文件未涉及UCI报告、固定的上行链路子帧用于发送UCI，也未涉及非PUCCH CC启用eIMTA的场景。 | 这是特征Q下的另一种具体实施方式。对比文件未提供任何与此相关的技术教导。因此，该特征未被公开。 |
| **特征T：其中，所述第一CC和所述第二CC是针对载波聚合(CA)操作配置的。** <br>**《直接公开》** | [0026]：“In embodiments in which the UE 108 is capable of utilizing carrier aggregation (CA), a number of CCs may be aggregated for communication between the eNB 104 and the UE 108.” | 对比文件明确其技术方案应用于载波聚合（CA）操作场景。这直接公开了技术特征T。 |
| **特征U：其中，所述第一CC和所述第二CC是针对双向连接操作配置的。** <br>**《未公开》** | 未发现相关描述。对比文件通篇讨论载波聚合（CA），未提及双连接（Dual Connectivity）操作。 | 目标专利中载波聚合和双连接是并列的两种多载波操作模式（见说明书[0007], [0009]）。对比文件仅涉及前者，未公开后者。因此，该特征未被公开。 |
<<<B>>><<<D>>><<<E>>><<<G>>><<<H>>><<<J>>><<<T>>>