对比文件名称：2012-02-16_WO2012020107A_发明申请_WO2012020107A1 HANDOVER LATENCY REDUCTION
目标专利名称：347在切换之后延迟对调度请求的触发CN106105313B
模型名称：DeepSeek
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：包括：确定已经发生从第一基站到第二基站的切换 <br> **《直接公开》** | [p0071] [0056] In an embodiment, the E-UTRAN 302 may transmit an RRCConnectionReconfiguration message 304 to the UE 300, possibly via another RAN. In turn, the UE transmits an RRCConnectionReconfigurationComplete message 306 to the E-UTRAN. The process terminates thereafter. <br> [p0072] [0057] The handover to E-UTRAN procedure shown in Figure 3 may be used when the network hands over the UE from another RAT to E-UTRA. | 对比文件明确描述了从其他RAT（第一基站所在的网络）到E-UTRAN（第二基站所在的网络）的切换过程，具体包括向UE发送RRC连接重配置消息以发起切换，UE随后完成重配置。这直接公开了UE确定已经发生从第一基站（源基站）到第二基站（目标E-UTRA基站）的切换。该过程在对比文件中用于实现切换，与目标专利中“确定已经发生切换”的作用相同，都是作为后续操作（如延迟调度请求或确定随机接入时机）的前提条件。因此，本领域技术人员能够毫无疑义地得出该技术特征。 |
| **技术特征B**：至少部分地基于确定在所述切换之后在所述移动设备处没有从所述第二基站接收到主信息块(MIB)，将对调度请求到所述第二基站的传输延迟预定时间段。 <br> **《未公开》** | 无直接对应原文。对比文件涉及MIB和延迟，但目的和机制不同。 | 对比文件虽然多次提及MIB以及获取MIB可能带来的延迟（例如[p0076][0062]指出PBCH TTI为40ms会导致切换延迟增加），但其核心发明构思是**通过提供同步指示和/或定时偏移信息，使得UE能够在不同步的情况下，无需获取MIB即可确定目标小区的帧极性（SFN奇偶性），从而提前发起随机接入（RACH）过程**，以**减少**切换延迟（参见[p0044][0043]，[p0082][0067]-[0069]）。而目标专利的技术特征B是基于**未收到MIB**这一条件，**主动延迟调度请求（SR）的传输**，以避免触发低效的随机接入，其目的是**在未获得定时信息时避免立即行动**，与对比文件“使UE能更早行动”的目的**相反**。对比文件从未教导或暗示基于未收到MIB去延迟一个调度请求的传输。因此，该技术特征既未被直接公开，也未被隐含公开。 |
| **技术特征C**：其中，所述延迟对所述调度请求的所述传输包括：延迟对所述调度请求的所述传输，直到满足条件为止。 <br> **《未公开》** | 无直接对应原文。 | 如对特征B的论述，对比文件的核心是使UE能够不依赖MIB而提前进行随机接入，并未涉及“延迟调度请求直到满足条件”这一操作逻辑。因此，该技术特征未被公开。 |
| **技术特征D**：其中，满足所述条件包括：从所述第二基站接收到所述MIB。 <br> **《未公开》** | 无直接对应原文。 | 对比文件确实提到在某些情况下（如网络不同步且无定时偏移信息时）UE需要获取MIB（例如图4、图5、图6中的流程），但获取MIB是作为进行随机接入的**一个可选或必需的步骤**，而不是作为“延迟调度请求”这一动作的**解除条件**。目标专利将“接收到MIB”作为延迟调度请求传输的满足条件，这一特定关联未被对比文件公开。 |
| **技术特征E**：还包括：确定在已经发生所述切换之前已经接收到系统信息块(SIB)。 <br> **《未公开》** | 无直接对应原文。 | 对比文件全文未提及“系统信息块(SIB)”或其在切换前是否被接收。因此，该技术特征未被公开。 |
| **技术特征F**：其中，所述预定时间段是至少部分地基于以下各项的：通过从所述第二基站接收的所述MIB来对上行链路定时的期望获取或者期望导出。 <br> **《未公开》** | 无直接对应原文。 | 对比文件未描述任何与“期望获取或导出来自MIB的上行链路定时”相关的“预定时间段”。对比文件中提及的时间段（如40ms的PBCH TTI）是MIB的传输周期，而非UE主动设置的、基于期望定时获取的延迟时间段。因此，该技术特征未被公开。 |
| **技术特征G**：还包括：确定要在所述切换之后向所述第二基站发送数据 <br> **《隐含公开》** | [p0073] [0058] ... it may be desirable for the UE to know whether the current SFN is even or odd before it can access the target E-UTRA cell after handover. <br> [p0099] [00114] ... such that the UE can infer the E-UTRA system frame polarity ... in order that a random access procedure can be initiated ... | 对比文件反复论述UE在切换后需要接入（access）目标E-UTRA小区，并可能发起随机接入过程（RACH）。随机接入过程是UE请求上行链路资源以发送数据（如调度请求、缓冲区状态报告或用户数据）的典型方式。因此，本领域技术人员从“UE需要在切换后接入目标小区”这一上下文可以合理推断，UE之所以要接入目标小区，是因为有上行通信的需求，这隐含了“确定要在切换之后向第二基站发送数据”这一前提。尽管对比文件未明确提及“发送数据”或检查缓冲区状态，但发起随机接入或任何上行链路接入的动机通常是为了传输数据。 |
| **技术特征H**：基于确定在所述切换之后还没有从所述第二基站接收到所述MIB，确定所述MIB不存在 <br> **《隐含公开》** | [p0076] [0062] ... However, the PBCH TTI is a 40ms interval, which leads to increased handover latency and interruption time. <br> 图4、图5、图6流程图中均有“获取MIB”的判断分支。 | 对比文件明确将“获取MIB”作为一个可能增加延迟的步骤，并在流程图（如图4、5、6）中将其设置为一个判断节点（例如，如果PRACH配置并非在所有帧中都相同，且网络不同步/无定时偏移，则UE需要获取MIB）。这些流程图逻辑隐含了UE需要判断是否已经成功获取MIB。如果UE尝试获取但尚未成功，或者根据条件判断需要获取但还未开始获取，则本领域技术人员可以合理推断UE能够“确定MIB不存在（即尚未收到）”。这种判断是执行流程图后续分支（是去获取MIB还是直接进行随机接入）的基础。 |
| **技术特征I**：将对所述调度请求的所述传输延迟所述预定时间段。 <br> **《未公开》** | 无直接对应原文。 | 该特征与特征B、C实质相关。如前述，对比文件未公开“延迟调度请求传输”这一动作。因此，该技术特征未被公开。 |
| **技术特征J**：还包括：至少部分地基于确定在所述切换之后已经接收到所述MIB，向所述第二基站发送所述调度请求。 <br> **《未公开》** | 无直接对应原文。 | 对比文件中，接收到MIB可能使得UE能够确定帧极性并进行随机接入（如图4、5流程），但并未将“接收到MIB”与“发送调度请求（SR）”这一特定动作关联起来。调度请求（SR）是在已建立上行同步的PUCCH上发送的，而对比文件讨论的是在未建立上行同步时发起随机接入（RACH）。两者是不同的上行资源请求机制。因此，该技术特征未被公开。 |
| **技术特征K**：还包括：在所述预定时间段到期之后，确定是否已经接收到所述MIB <br> **《未公开》** | 无直接对应原文。 | 对比文件没有描述设置一个“预定时间段”并在其到期后检查MIB接收状态的机制。因此，该技术特征未被公开。 |
| **技术特征L**：响应于确定来自所述第二基站的所述MIB继续不存在，将对所述调度请求的所述传输进一步延迟第二预定时间段。 <br> **《未公开》** | 无直接对应原文。 | 该特征涉及渐进式延迟机制，对比文件完全没有提及。因此，该技术特征未被公开。 |
| **技术特征M**：还包括：响应于确定已经接收到所述MIB，发送所述调度请求。 <br> **《未公开》** | 无直接对应原文。 | 同特征J，对比文件未将“接收到MIB”与“发送调度请求”关联。因此，该技术特征未被公开。 |
| **技术特征N**：还包括：在所述第二预定时间段内未接收到所述MIB的情况下，发起无线链路失败(RLF)过程。 <br> **《未公开》** | 无直接对应原文。 | 对比文件未提及无线链路失败（RLF）过程，也未将其与MIB接收失败相关联。因此，该技术特征未被公开。 |
| **技术特征O**：其中，所述预定时间段是至少部分地基于预定数量的长期演进(LTE)帧的。 <br> **《未公开》** | 无直接对应原文。 | 对比文件未描述基于LTE帧数量的预定时间段用于延迟调度请求。因此，该技术特征未被公开。 |
| **技术特征P**：包括：用于确定已经发生从第一基站到第二基站的切换的单元 <br> **《直接公开》** | [p0071] [0056] In an embodiment, the E-UTRAN 302 may transmit an RRCConnectionReconfiguration message 304 to the UE 300, possibly via another RAN. In turn, the UE transmits an RRCConnectionReconfigurationComplete message 306 to the E-UTRAN. The process terminates thereafter. <br> [p0072] [0057] The handover to E-UTRAN procedure shown in Figure 3 may be used when the network hands over the UE from another RAT to E-UTRA. | 该装置特征与方法特征A相对应。对比文件公开了UE执行从其他RAT到E-UTRAN的切换过程，这必然意味着UE中包含了用于实现该功能的模块或单元（例如，处理接收到的RRCConnectionReconfiguration消息并执行切换的处理器或控制模块）。本领域技术人员能够毫无疑义地从公开的UE行为中得出其具有“用于确定已经发生切换的单元”。 |
| **技术特征Q**：用于至少部分地基于确定在所述切换之后在所述装置处没有从所述第二基站接收到主信息块(MIB)，将对调度请求到所述第二基站的传输延迟预定时间段的单元。 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征B相对应。如对特征B的论述，对比文件未公开基于未收到MIB而延迟调度请求传输的技术方案，因此也不可能公开实现该功能的专用单元。 |
| **技术特征R**：其中，所述用于延迟对所述调度请求的所述传输的单元延迟所述调度请求，直到已经从所述第二基站接收到所述MIB为止。 <br> **《未公开》** | 无直接对应原文。 | 该特征与方法特征C、D相对应。对比文件未公开该技术方案，因此也未公开对应的单元。 |
| **技术特征S**：还包括：用于确定在已经发生所述切换之前已经接收到系统信息块(SIB)的单元。 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征E相对应。对比文件未提及SIB，因此也未公开对应的单元。 |
| **技术特征T**：其中，所述预定时间段是至少部分地基于以下各项的：通过从所述第二基站接收的所述MIB来对上行链路定时的期望获取或期望导出。 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征F相对应。对比文件未公开该技术方案，因此也未公开对应的单元或该时间段的具体依据。 |
| **技术特征U**：还包括：用于确定要在所述切换之后向所述第二基站发送数据的单元 <br> **《隐含公开》** | [p0073] [0058] ... it may be desirable for the UE to know whether the current SFN is even or odd before it can access the target E-UTRA cell after handover. <br> [p0099] [00114] ... in order that a random access procedure can be initiated ... | 该装置特征与方法特征G相对应。如对特征G的论述，对比文件隐含了UE在切换后有接入目标小区以上行发送的需求。因此，本领域技术人员可以合理推断，实现该功能的UE中必然包含用于作出此确定的功能单元（例如，缓冲区管理模块或上行控制逻辑）。 |
| **技术特征V**：用于基于确定在所述切换之后还没有从所述第二基站接收到所述MIB，确定所述MIB不存在的单元 <br> **《隐含公开》** | [p0076] [0062] ... However, the PBCH TTI is a 40ms interval, which leads to increased handover latency and interruption time. <br> 图4、图5、图6流程图中均有“获取MIB”的判断分支。 | 该装置特征与方法特征H相对应。如对特征H的论述，对比文件的流程图逻辑隐含了UE需要判断MIB获取状态。因此，可以合理推断UE中包含了用于执行此判断的功能单元（例如，解码PBCH的模块及相关的控制逻辑）。 |
| **技术特征W**：用于将对所述调度请求的所述传输延迟所述预定时间段的单元。 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征I相对应。对比文件未公开延迟调度请求传输，因此也未公开对应的单元。 |
| **技术特征X**：还包括：用于至少部分地基于确定在所述切换之后已经接收到所述MIB，向所述第二基站发送所述调度请求的单元。 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征J相对应。对比文件未公开该技术方案，因此也未公开对应的单元。 |
| **技术特征Y**：还包括：用于在所述预定时间段到期之后，确定是否已经接收到所述MIB的单元 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征K相对应。对比文件未公开该技术方案，因此也未公开对应的单元。 |
| **技术特征Z**：用于响应于确定来自所述第二基站的所述MIB继续不存在，将对所述调度请求的所述传输进一步延迟第二预定时间段的单元。 <br> **《未公开》** | 无直接对应原文。 | 该装置特征与方法特征L相对应。对比文件未公开该技术方案，因此也未公开对应的单元。 |
<<<A>>><<<P>>><<<g>>><<<h>>><<<u>>><<<v>>>