好的，我们开始进行评估。
### 对比文件名称
2007-02-22_US2007041349A_发明申请_US20070041349A1 Method and apparatus for controlling reliability of feedback signal in a mobile communication system supporting HARQ
### 目标专利名称
750通信中的混合自动重传请求定时CN106165330B
### 模型名称
当前使用的模型名称
---
### 特征比对表格
| 技术特征描述以及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A：** 所述方法包括：在网络装置中并且基于用户终端的能力，在可用的多个混合自动重传请求简档之中定义针对所述用户终端的混合自动重传请求，<br><br>**《未公开》** | 无直接对应内容。 | 对比文件主要描述了基于服务质量（QoS）要求或数据包大小来定义HARQ简档（Tx HARQ profile, Rx HARQ profile），以控制反馈信号的可靠性（参见[0055]-[0056], [0066]-[0068]）。虽然对比文件提到了“UE能力”（UE capabilities）在通信系统中的一般性作用（参见[0008]），但其HARQ简档的定义核心是基于上层业务的服务质量要求（QoS requirement），而非基于用户终端（UE）自身的处理能力（如处理速度、缓冲器大小等）。目标专利明确强调“基于用户终端的能力”来定义HARQ简档，这与对比文件基于业务QoS的定义基础不同。对比文件并未公开或隐含公开“基于用户终端的能力”这一技术特征。 |
| **技术特征B：** 所述多个混合自动重传请求简档至少在所述用户终端和基站之间的通信链路的一端处提供不同的处理时间，<br><br>**《未公开》** | 无直接对应内容。 | 对比文件中的HARQ简档（尤其是Rx HARQ profile）旨在为不同的数据包提供不同的反馈信号可靠性（如NACK/ACK错误率），而不是提供不同的“处理时间”。目标专利中的“处理时间”明确指代HARQ流程中的时间间隔（如从接收到发送反馈的间隔）。对比文件虽然涉及HARQ进程和定时（如HARQ cycle），但其核心是控制信令的可靠性，而非为不同的简档配置不同的处理时间。因此，对比文件并未公开或隐含公开该项特征。 |
| **技术特征C：** 其中所述混合自动重传请求简档指示 -下行链路传输在所述用户终端中被接收与对应的上行链路控制信息被预期从所述用户终端被发射之间的第一时间间隔，<br><br>**《未公开》** | 无直接对应内容。 | 对比文件详细描述了HARQ的反馈流程（参见[0013]），即接收端接收数据包后进行CRC校验，然后发送ACK/NACK。但是，对比文件完全没有定义或提及从“下行链路传输接收”到“上行链路控制信息发射”之间的特定、可配置的“第一时间间隔”。对比文件中的定时关系是固定的或由系统预定义的，并非可以灵活配置的HARQ简档的一部分。该项特征未被公开。 |
| **技术特征D：** 以及-所述上行链路控制信息从所述用户终端被发射与对应的下行链路重传被预期最早在所述用户终端中被接收之间的第二时间间隔，<br><br>**《未公开》** | 无直接对应内容。 | 类似地，对比文件描述了发送NACK后，发射端进行重传（参见[0013]步骤208），但未定义从“上行控制信息发射”到“最早预期重传接收”之间的一个可配置的“第二时间间隔”。对比文件中的重传时机是隐含在HARQ协议中的，不是作为HARQ简档的一个参数来定义和指示的。该项特征未被公开。 |
| **技术特征E：** 或者其中所述混合自动重传请求简档指示 -上行链路传输在基站中被接收与对应的下行链路信息被预期从所述基站被发射之间的第三时间间隔，<br><br>**《未公开》** | 无直接对应内容。 | 对比文件主要关注下行链路数据的HARQ流程，对上行链路HARQ的描述较少。即使考虑上行链路，对比文件也未定义从“上行链路传输接收”到“下行链路信息（如调度授权或反馈）发射”之间的一个可配置的“第三时间间隔”。该项特征未被公开。 |
| **技术特征F：** 以及-所述下行链路信息从所述基站被发射与对应的上行链路重传被预期最早在所述基站中被接收之间的第四时间间隔。<br><br>**《未公开》** | 无直接对应内容。 | 同理，对比文件未定义从“下行链路信息发射”到“最早预期上行链路重传接收”之间的一个可配置的“第四时间间隔”。该项特征未被公开。 |
| **技术特征G：** 其中所述混合自动重传请求简档在对小区的初始接入期间被预定义或被定义。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件提到Rx HARQ profile的配置可以通过高层信令或在呼叫建立时信令化（参见[0107]“The size threshold may be signaled during a call setup”），但并未明确提及在“对小区的初始接入期间”进行定义或预定义。目标专利中的“初始接入”是一个特定的时间点，与一般的“呼叫建立”不完全相同。对比文件未公开或隐含公开此项特征。 |
| **技术特征H：** 其中所述方法还包括：通过调节为处理所述系统中的数据和相关控制信号而预留的时间来提供灵活的混合自动重传请求定时。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件的核心是调节反馈信号的可靠性（如通过功率偏移或重复次数），而不是调节为处理数据和信号而“预留的时间”。目标专利强调的是通过改变处理时间来提供灵活的HARQ定时，这与对比文件通过改变信令可靠性来调整错误率的技术方案存在本质区别。对比文件未公开此项特征。 |
| **技术特征I：** 其中所述上行链路控制信息和所述下行链路信息中的至少一个包括确认消息或者否定确认消息。<br><br>**《直接公开》** | [0013] “If the receiver succeeds in the CRC verification...the receiver feeds back an ACKnowledgement (ACK) signal...the receiver...feeds back a Negative ACKnowledgement (NACK) signal...”<br><br>[0042] “The HARQ feedback signal is an ACK or NACK signal between a transmitter and a receiver.” | 对比文件明确、详细地公开了HARQ流程中的反馈信号是ACK或NACK消息。无论是上行控制信息（在HARQ中通常为ACK/NACK）还是下行链路信息（例如，在类似上行HARQ的场景中，下行链路信息也可以是ACK/NACK），对比文件都明确教导了其可以包含ACK或NACK消息。这是HARQ技术的基础，对比文件对此进行了明确公开。 |
| **技术特征J：** 其中所述上行链路传输包括上行链路被调度的消息。<br><br>**《隐含公开》** | [0090] “On the uplink, this means that a UE is allowed to send data in the next transmission time interval by a Node B scheduler.” <br><br>[0024] “...a per packet control information generator generates per packet control information including at least the size of a user data packet...”<br><br>[0044] “For an uplink service, the Tx HARQ entity 372 and the Rx HARQ entity 312 are provided in the UE and the Node B, respectively.” | 对比文件明确讨论了上行链路服务，其中UE作为发射端，Node B作为接收端（[0044]）。在上行链路HARQ操作中，UE发送的上行传输通常是基于Node B的调度授权进行的（[0090]）。这种被调度的上行数据传输即为“上行链路被调度的消息”。虽然对比文件没有直接使用这个精确的词汇，但本领域技术人员可以合理推断出，在上行HARQ流程中，UE所发送的上行传输就是响应于基站调度授权的被调度消息。 |
| **技术特征K：** 其中所述下行链路信息包括上行链路调度授权消息。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件主要将下行链路信息描述为HARQ的反馈信号（ACK/NACK）或下行数据包。虽然上行调度是存在的（[0090]），但该调度授权消息（UL grant）是作为控制信息在下行链路上发送的，它本身并不是一个“下行链路信息”被包含在HARQ简档所定义的流程中（即特征E/F中描述的与上行链路重传对应的下行信息）。对比文件并未将“上行链路调度授权消息”作为与上行重传定时相关的HARQ简档指示的一部分。 |
| **技术特征L：** 其中所述混合自动重传请求简档是以下中的一个或多个：设备特定的、设备类型特定的、小区特定的和服务类型特定的。<br><br>**《未公开》** | [0068] “Like a Tx HARQ profile, an Rx HARQ profile is defined for data with the same QoS requirement.” <br><br>[0052]-[0054] 描述了根据上层业务（如VoIP, FTP）的不同QoS要求来定义不同的HARQ profile。 | 对比文件明确教导了HARQ简档是“服务类型特定的”（service-specific），因为它根据不同的QoS要求（如VoIP和FTP）定义不同的简档。但是，对比文件并未公开或隐含公开HARQ简档是“设备特定的”（即针对单个UE）、“设备类型特定的”（如针对MTC设备）或“小区特定的”。对比文件强调的是根据业务流（data flow）的QoS来定义，而非根据设备本身类别或小区。因此，该特征仅被部分公开，但不足以认定为公开。 |
| **技术特征M：** 其中定义所述混合自动重传请求简档中涉及的可变数目或固定数目的不同的混合自动重传请求进程。<br><br>**《未公开》** | [0046] “For parallel HARQ operations, the Tx HARQ entity 372 includes a plurality of Tx HARQ processors 355, 360, 365 and 370, and the Rx HARQ entity includes a plurality of Rx HARQ processors 315, 320, 325 and 330.” | 对比文件描述了多个HARQ处理器（进程）用于并行操作，但这是HARQ系统的一般性特征。对比文件没有公开或暗示HARQ简档本身可以定义（define）所涉及的HARQ进程的数目是“可变的”或“固定的”。HARQ简档在对比文件中是用于定义发送功率和重传次数等参数，而不是用于定义HARQ进程的数目。 |
| **技术特征N：** 其中所述方法还包括：定义针对所述混合自动重传请求简档中涉及的不同的混合自动重传请求进程的可变传输时间间隔TTI长度。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件完全没有提及“传输时间间隔（TTI）长度”，更不用说根据HARQ进程来定义“可变的TTI长度”。对比文件中的所有操作都是基于固定的TTI长度（如一个子帧）进行的。该项特征未被公开。 |
| **技术特征O：** 其中多个混合自动重传请求简档共存于包括频率和时间资源的共同资源空间中。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件描述了多个HARQ简档（如VoIP和FTP的简档）可以用于不同的数据流，但并未明确说明这些使用不同简档的传输是“共存于包括频率和时间资源的共同资源空间中”。虽然这在OFDMA系统中是隐含的，但对比文件并未将其作为HARQ简档操作的一个技术特征或优点进行任何讨论或公开。 |
| **技术特征P：** 其中所述方法还包括：定义所述用户终端是具有快速响应能力的用户终端或者所述用户终端是具有较低的混合自动重传请求回路延迟能力的用户终端。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件完全没有涉及根据用户终端的“响应能力”或“回路延迟能力”来对UE进行分类或定义。对比文件关注的是业务类型（QoS）对反馈可靠性的要求，而非UE自身的处理速度或能力等级。 |
| **技术特征Q：** 其中所述方法还包括：响应于所述系统中的预定事件，在活跃会话期间针对所述用户终端动态地重新配置混合自动重传请求回路延迟。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件没有公开任何关于在“活跃会话期间动态重新配置HARQ回路延迟”的内容。对比文件中的HARQ简档配置是半静态的，例如在呼叫建立时信令化（[0107]），并不涉及响应于“预定事件”的动态重配置。 |
| **技术特征R：** 其中所述方法还包括：定义针对具有不同的混合自动重传请求简档的用户终端的共享控制信道中的分离的HARQ-ACK控制信道部分。<br><br>**《未公开》** | 无直接对应内容。 | 对比文件完全没有公开关于“共享控制信道”以及在其中定义“分离的HARQ-ACK控制信道部分”的任何内容。 |
| **技术特征S：** 其中所述方法还包括：根据所述混合自动重传请求简档，定义混合自动重传请求缓冲器每子帧的大小与混合自动重传请求进程的最大数目中的至少一个。<br><br>**《未公开》** | [0048] “...stores the channel-coded data in a buffer (not shown) for retransmission later.”<br><br>[0054] “...setting a relatively large maximum retransmission number, for example, 8 for data B.” | 对比文件提到了HARQ缓冲器和最大重传次数，但从未公开“根据HARQ简档来定义缓冲器每子帧的大小”或“HARQ进程的最大数目”。对比文件中的最大重传次数是HARQ简档（Tx HARQ profile）的一部分，但这不是HARQ进程的最大数目。缓冲器大小在对比文件中是固定的，不随简档变化。 |
| **技术特征T：** 其中所述方法还包括：定义针对所述用户终端的双向混合自动重传请求简档，所述双向混合自动重传请求简档包括针对所述用户终端的下行链路混合自动重传请求简档和上行链路混合自动重传请求简档。<br><br>**《未公开》** | [0044] “For a downlink service, the Tx HARQ entity 372 and the Rx HARQ entity 312 are provided in a Node B and a UE, respectively. For an uplink service, the Tx HARQ entity 372 and the Rx HARQ entity 312 are provided in the UE and the Node B, respectively.”<br><br>[0066] “The Tx HARQ profile provides information about the transmit power...and the Rx HARQ profile indicates the reliability of a NACK signal...” | 对比文件区分了下行和上行服务，并定义了Tx HARQ profile和Rx HARQ profile。然而，这些简档是基于发射和接收角色定义的，而非基于链路方向（上行/下行）。一个“双向HARQ简档”需要将针对下行链路的HARQ简档和针对上行链路的HARQ简档组合成一个针对用户终端的统一简档。对比文件没有公开这样的组合或“双向”概念。 |
### 公开性判断总结
根据以上分析，对比文件公开情况如下：
* **直接公开**：技术特征 **I**。
* **隐含公开**：技术特征 **J**。
* **未公开**：技术特征 A, B, C, D, E, F, G, H, K, L, M, N, O, P, Q, R, S, T。
根据输出格式的要求，在回答的结尾插入对应的代码。
<<<I>>>
<<<j>>>