对比文件名称：2012-10-25_US2012269180A_发明申请_US20120269180A1 METHOD AND APPARATUS FOR SUPPORTING SYNCHRONOUS HARQ TRANSMISSION
目标专利名称：750通信中的混合自动重传请求定时CN106165330B
本次调用的模型名称：deepseek-reasoner
### 特征比对表格
| 技术特征描述以及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：所述方法包括：在网络装置中并且基于用户终端的能力，在可用的多个混合自动重传请求简档之中定义针对所述用户终端的混合自动重传请求简档。<br><br>**《未公开》** | 对比文件[0039]：“BS配置UE在一个或多个小区（部分或全部）上操作。”<br>对比文件[0045]：“与LTE和LTE-A中的UE相比，根据本发明的UE被称为新UE...”。 | 对比文件虽由基站（网络装置）配置UE，但其配置的HARQ定时关系是基于Pcell和Scell的具体上下行配置组合来确定的，而非基于用户终端的能力从“多个可用的HARQ简档”中选择一个。对比文件不存在“多个HARQ简档”的概念，也未公开基于UE能力进行简档选择的机制。 |
| **技术特征B**：所述多个混合自动重传请求简档至少在所述用户终端和基站之间的通信链路的一端处提供不同的处理时间。<br><br>**《未公开》** | 对比文件全文未公开“多个混合自动重传请求简档”的概念。 | 该技术特征建立在“多个混合自动重传请求简档”存在的基础上。由于对比文件未公开技术特征A中的“多个简档”概念，也未公开任何等同于“简档”的实体在不同链路端提供不同处理时间的技术方案，因此该特征未被公开。 |
| **技术特征C**：下行链路传输在所述用户终端中被接收与对应的上行链路控制信息被预期从所述用户终端被发射之间的第一时间间隔。<br><br>**《未公开》** | 对比文件全文主要涉及上行链路（UL）的同步HARQ传输定时，未明确针对下行链路HARQ定义“第一时间间隔”。 | 对比文件的发明名称和发明内容均聚焦于“支持上行链路数据的同步HARQ传输”。虽然系统必然存在下行HARQ，但对比文件未公开任何HARQ简档指示下行链路接收与上行控制信息（ACK/NACK）之间的特定第一时间间隔。 |
| **技术特征D**：所述上行链路控制信息从所述用户终端被发射与对应的下行链路重传被预期最早在所述用户终端中被接收之间的第二时间间隔。<br><br>**《未公开》** | 对比文件全文未定义下行链路HARQ重传的定时。 | 对比文件主要定义了UL HARQ的定时（PUSCH -> PHICH -> PUSCH重传），并未定义UL控制信息（DL ACK/NACK）与DL重传之间的第二时间间隔。 |
| **技术特征E**：上行链路传输在基站中被接收与对应的下行链路信息被预期从所述基站被发射之间的第三时间间隔。<br><br>**《直接公开》** | 对比文件[0017]：“当UE在下行链路子帧i中接收PHICH时，该PHICH指示上行链路子帧i-k中的PUSCH的ACK/NACK”。<br>对比文件[0015]：“假设UE在下行链路子帧n中接收PHICH，该PHICH控制上行链路子帧n+k中的PUSCH。” | 对比文件明确公开了PUSCH（上行链路传输）与对应的PHICH（下行链路信息）之间的定时关系（例如PUSCH在子帧i-k，PHICH在子帧i）。该定时关系正是目标专利所定义的“上行链路传输在基站中被接收与对应的下行链路信息被预期从基站被发射之间的第三时间间隔”。本领域技术人员可以直接地、毫无疑义地确定该技术特征。 |
| **技术特征F**：所述下行链路信息从所述基站被发射与对应的上行链路重传被预期最早在所述基站中被接收之间的第四时间间隔。<br><br>**《直接公开》** | 对比文件[0015]：“假设UE在下行链路子帧n中接收PHICH，该PHICH控制上行链路子帧n+k中的PUSCH。”<br>对比文件说明书全文的表格（如Table 2, 3等）定义了PHICH到PUSCH重传的定时。 | 对比文件明确公开了PHICH（下行链路信息）与对应的PUSCH重传（上行链路重传）之间的定时关系（例如PHICH在子帧n，PUSCH重传在子帧n+k）。该定时关系正是目标专利所定义的第四时间间隔。本领域技术人员可以直接地、毫无疑义地确定该技术特征。 |
| **技术特征G**：所述混合自动重传请求简档在对小区的初始接入期间被预定义或被定义。<br><br>**《隐含公开》** | 对比文件[0039]：“BS配置UE在一个或多个小区上操作”。<br>对比文件[0050]：“预先配置从PDCCH和PHICH到PUSCH的定时关系以及从PUSCH到PHICH的定时关系”。 | 对比文件虽未明确使用“初始接入”一词，但UE在小区中操作必然经历初始接入或RRC连接重配置过程。对比文件中公开的HARQ定时关系是针对特定CA配置而预定义的标准表格，且在BS配置UE在小区上操作时被定义。本领域技术人员可以合理推断出该HARQ定时关系是在对小区初始接入期间被预定义或定义的。 |
| **技术特征H**：通过调节为处理所述系统中的数据和相关控制信号而预留的时间来提供灵活的混合自动重传请求定时。<br><br>**《直接公开》** | 对比文件[0024]：“本发明提供了一种在多个CA小区采用的上下行配置不相同时支持PUSCH的同步HARQ传输的方法和装置。”<br>对比文件[0081]：“如果BS完全能够在3ms内完成该处理...如果BS不能在3ms内完成处理...”。 | 对比文件的核心即在于通过重新配置HARQ定时关系来支持不同配置下的HARQ传输，这本质上就是通过调节为处理数据和相关控制信号而预留的时间来实现灵活的HARQ定时。例如，对比文件明确将处理时间从标准的4ms调节至3ms，这正是该技术特征的具体体现。 |
| **技术特征I**：所述上行链路控制信息和所述下行链路信息中的至少一个包括确认消息或者否定确认消息。<br><br>**《直接公开》** | 对比文件[0009]：“BS在物理混合自动重传指示信道(PHICH)中承载HARQ指示信息”。 | 对比文件明确公开了下行链路信息（PHICH）包括确认消息或否定确认消息（HARQ ACK/NACK）。本领域技术人员可以直接地、毫无疑义地确定该技术特征。 |
| **技术特征J**：所述上行链路传输包括上行链路被调度的消息。<br><br>**《直接公开》** | 对比文件[0009]：“UE在物理上行链路共享信道(PUSCH)中承载上行链路数据”。 | 对比文件明确公开了上行链路传输（PUSCH）包括上行链路被调度的消息。本领域技术人员可以直接地、毫无疑义地确定该技术特征。 |
| **技术特征K**：所述下行链路信息包括上行链路调度授权消息。<br><br>**《直接公开》** | 对比文件[0009]：“BS在物理下行链路控制信道(PDCCH)中承载PUSCH调度和控制信息”。 | 对比文件明确公开了下行链路信息（PDCCH）包括上行链路调度授权消息。本领域技术人员可以直接地、毫无疑义地确定该技术特征。 |
| **技术特征L**：所述混合自动重传请求简档是以下中的一个或多个：设备特定的、设备类型特定的、小区特定的和服务类型特定的。<br><br>**《隐含公开》** | 对比文件[0045]：“与LTE和LTE-A中的UE相比，根据本发明的UE被称为新UE...”。<br>对比文件说明书全文根据Pcell和Scell的不同配置定义了不同的定时关系。 | 对比文件公开的HARQ定时关系依赖于具体的Pcell和Scell配置（即小区特定），并且区分了“新UE”和“传统UE”（即设备类型特定）。虽然对比文件未使用“简档”一词，但其公开的定时关系本质上具有小区特定和设备类型特定的属性。本领域技术人员可以合理推断出该技术特征。 |
| **技术特征M**：定义所述混合自动重传请求简档中涉及的可变数目或固定数目的不同的混合自动重传请求进程。<br><br>**《直接公开》** | 对比文件[0022]：“PUSCH的一次传输的定时位置与后续重传的定时位置之间的定时关系是恒定的，这在本文中称为同步HARQ传输。” | 对比文件明确公开了同步HARQ传输。在同步HARQ中，定时关系恒定，这必然定义了固定数目的HARQ进程。本领域技术人员可以直接地、毫无疑义地确定该技术特征。 |
| **技术特征N**：定义针对所述混合自动重传请求简档中涉及的不同的混合自动重传请求进程的可变传输时间间隔TTI长度。<br><br>**《未公开》** | 对比文件全文未提及可变传输时间间隔（TTI）长度。 | 对比文件中的所有定时关系均基于固定的1ms TTI（子帧）长度。对比文件未公开任何关于可变TTI长度的内容，本领域技术人员也无法从对比文件中合理推断出该技术特征。 |
| **技术特征O**：多个混合自动重传请求简档共存于包括频率和时间资源的共同资源空间中。<br><br>**《未公开》** | 对比文件全文未公开多个HARQ简档共存的概念。 | 对比文件仅针对特定CA场景配置一套HARQ定时关系，不存在多个HARQ简档共存于共同资源空间中的技术方案。该特征未被对比文件公开。 |
| **技术特征P**：定义所述用户终端是具有快速响应能力的用户终端或者所述用户终端是具有较低的混合自动重传请求回路延迟能力的用户终端。<br><br>**《隐含公开》** | 对比文件[0081]：“如果BS完全能够在3ms内完成该处理...如果BS不能在3ms内完成处理...”。<br>对比文件[0117]：“UE不必等待整个下行链路子帧结束才解码PDCCH和PHICH，因此UE有更多时间处理PDCCH和PHICH。另一种处理方法是...允许UE更快地接收PDCCH和PHICH。” | 对比文件明确讨论了不同的处理时间（3ms vs 4ms）对调度的影响，并提及了UE更快接收PDCCH/PHICH的能力。这隐含地定义了用户终端或基站具有不同的响应能力（快速响应/低回路延迟能力）。本领域技术人员可以合理推断出系统根据用户终端的能力来应用不同的处理定时。 |
| **技术特征Q**：响应于所述系统中的预定事件，在活跃会话期间针对所述用户终端动态地重新配置混合自动重传请求回路延迟。<br><br>**《未公开》** | 对比文件全文未公开动态重配置的概念。 | 对比文件中的HARQ定时关系是在配置CA时设定的，并未公开在活跃会话期间响应于预定事件进行动态重配置的机制。该特征未被对比文件公开。 |
| **技术特征R**：定义针对具有不同的混合自动重传请求简档的用户终端的共享控制信道中的分离的HARQ-ACK控制信道部分。<br><br>**《未公开》** | 对比文件全文未公开分离的HARQ-ACK控制信道部分。 | 对比文件未针对不同简档的UE定义分离的控制信道部分。该特征未被对比文件公开。 |
| **技术特征S**：根据所述混合自动重传请求简档，定义混合自动重传请求缓冲器每子帧的大小与混合自动重传请求进程的最大数目中的至少一个。<br><br>**《未公开》** | 对比文件全文未公开根据简档定义缓冲器大小。 | 对比文件未公开根据HARQ定时配置来定义缓冲器大小的技术方案。该特征未被对比文件公开。 |
| **技术特征T**：定义针对所述用户终端的双向混合自动重传请求简档，所述双向混合自动重传请求简档包括针对所述用户终端的下行链路混合自动重传请求简档和上行链路混合自动重传请求简档。<br><br>**《未公开》** | 对比文件全文主要涉及上行链路HARQ。 | 对比文件的发明名称为“支持上行链路数据的同步HARQ传输”，其说明书也主要围绕上行链路HARQ定时。对比文件未公开针对用户终端的双向HARQ简档。该特征未被对比文件公开。 |
<<<E>>><<<F>>><<<H>>><<<I>>><<<J>>><<<K>>><<<M>>><<<g>>><<<l>>><<<p>>>