对比文件名称：2012-02-16_US2012040674A_发明申请_US20120040674A1 Handover Latency Reduction
目标专利名称：在切换之后延迟对调度请求的触发CN106105313B
本次调用模型名称：DeepSeek-R1
特征比对表格：
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：包括：确定已经发生从第一基站到第二基站的切换 《直接公开》 | [0045] “The embodiments described herein relate to mechanisms to reduce the latency for a ‘Handover-to-E-UTRA’ procedure, i.e., handover from a source cell with another RAT to a target E-UTRA cell.” <br> [0056] “FIG. 3 is a flow diagram illustrating handover of a UE 300 to an E-UTRAN 302 from a network having a RAT other than E-UTRA, according to an embodiment of the present disclosure.” <br> [0057] “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.” | 对比文件全文主题即为减少切换延迟，明确描述了从源小区（第一基站）到目标E-UTRA小区（第二基站）的切换过程。图3及其说明具体展示了UE接收切换命令（RRCConnectionReconfiguration）以执行到E-UTRAN的切换。因此，本领域技术人员能够毫无疑义地确定对比文件公开了UE确定已经发生从第一基站到第二基站的切换这一技术特征。 |
| **技术特征B**：至少部分地基于确定在所述切换之后在所述移动设备处没有从所述第二基站接收到主信息块(MIB)，将对调度请求到所述第二基站的传输延迟预定时间段。 《未公开》 | 无对应内容。 | 对比文件的核心目的是**减少**切换延迟，让UE能够**尽快**发起随机接入（RA）过程，其技术手段是通过信令告知UE同步状态或定时偏移，从而使得UE在**无需等待接收和解码MIB**的情况下即可发起RA。这与目标专利“基于未收到MIB而延迟调度请求(SR)传输”的技术手段目的相反。对比文件全文未提及“调度请求(Scheduling Request, SR)”的概念，也未记载基于未收到MIB而延迟任何传输（尤其是SR传输）的技术方案。因此，该技术特征未被对比文件公开。 |
| **技术特征C**：其中，所述延迟对所述调度请求的所述传输包括：延迟对所述调度请求的所述传输，直到满足条件为止。 《未公开》 | 无对应内容。 | 如特征B所述，对比文件未涉及“调度请求(SR)”及其延迟。因此，“延迟直到满足条件为止”这一具体延迟方式也未被公开。 |
| **技术特征D**：其中，满足所述条件包括：从所述第二基站接收到所述MIB。 《未公开》 | 无对应内容。 | 该特征是特征C中“条件”的具体化。由于特征C未被公开，且对比文件中UE在需要MIB时是主动去“获取”(obtain)而非将其作为延迟后触发的“条件”，因此该特征未被公开。 |
| **技术特征E**：还包括：确定在已经发生所述切换之前已经接收到系统信息块(SIB)。 《未公开》 | 无对应内容。 | 对比文件提到了在切换命令或广播系统信息中传输同步指示器（如`synchronisedInterRatHo`），这可能涉及系统信息，但并未明确提及“系统信息块(SIB)”这一特定术语，也未记载UE在切换前确定已经接收到SIB的动作。因此，该特征未被直接或隐含公开。 |
| **技术特征F**：其中，所述预定时间段是至少部分地基于以下各项的：通过从所述第二基站接收的所述MIB来对上行链路定时的期望获取或者期望导出。 《未公开》 | [0063] “However, the PBCH TTI is a 40 ms interval, which leads to increased handover latency and interruption time.” | 对比文件提到PBCH（承载MIB）的传输时间间隔（TTI）为40ms，这可能导致切换延迟增加。但这只是描述MIB本身的传输特性，并非目标专利中UE为了“期望获取或导出上行链路定时”而主动设置的“预定时间段”。目标专利的“预定时间段”是UE主动延迟SR触发所采用的定时器值，其依据是对获取MIB所需时间的预期。对比文件并未公开将MIB的期望获取时间作为延迟触发某个动作（如SR）的时间基准。因此，该特征未被公开。 |
| **技术特征G**：还包括：确定要在所述切换之后向所述第二基站发送数据 《未公开》 | 无对应内容。 | 对比文件描述了UE在切换后执行随机接入（RA）过程以接入目标小区。RA过程通常用于初始接入、上行同步或资源请求，但对比文件并未明确提及UE“确定要发送数据”这一触发条件或判断步骤。因此，该特征未被公开。 |
| **技术特征H**：基于确定在所述切换之后还没有从所述第二基站接收到所述MIB，确定所述MIB不存在 《隐含公开》 | [0062] 图4流程：在块404判断PRACH配置是否在所有无线帧中都相同，若否（“no”），则进入块408“获取MIB（通过解码PBCH）”。<br> [0072] 图5流程：在块504判断PRACH配置是否在所有帧中都相同，若否（“no”），则进入块508判断RAN是否同步，若否（“no”），则进入块514“获取MIB”。 | 对比文件的流程图中明确显示，当PRACH配置并非在所有帧都相同时（即需要知道SFN极性），如果网络未同步（且无定时偏移信令），则UE需要执行“获取MIB”的步骤。本领域技术人员可以合理推断，UE决定去“获取MIB”这一动作，必然是基于它“确定当前没有MIB”或“MIB信息不存在”这一前提判断。因此，对比文件隐含公开了“基于确定在切换之后还没有从第二基站接收到MIB，确定MIB不存在”这一技术特征。 |
| **技术特征I**：将对所述调度请求的所述传输延迟所述预定时间段。 《未公开》 | 无对应内容。 | 该特征是特征B的核心动作。如前所述，对比文件未涉及调度请求（SR）及其延迟。因此，该特征未被公开。 |
| **技术特征J**：还包括：至少部分地基于确定在所述切换之后已经接收到所述MIB，向所述第二基站发送所述调度请求。 《未公开》 | 无对应内容。 | 对比文件中，UE获取MIB后（图4的408之后，图5的514之后），接下来的动作是“执行随机接入(RA)”（图4的410，图5的516），而非“发送调度请求(SR)”。调度请求(SR)和随机接入(RA)是LTE中两种不同的上行资源请求机制。因此，该特征未被公开。 |
| **技术特征K**：还包括：在所述预定时间段到期之后，确定是否已经接收到所述MIB 《未公开》 | 无对应内容。 | 这是目标专利中延迟后进行检查的步骤。对比文件没有描述任何“预定时间段”到期后进行检查的逻辑。因此，该特征未被公开。 |
| **技术特征L**：响应于确定来自所述第二基站的所述MIB继续不存在，将对所述调度请求的所述传输进一步延迟第二预定时间段。 《未公开》 | 无对应内容。 | 这是目标专利中可能的重试或延长延迟机制。对比文件完全没有相关描述。因此，该特征未被公开。 |
| **技术特征M**：还包括：响应于确定已经接收到所述MIB，发送所述调度请求。 《未公开》 | 无对应内容。 | 同特征J，对比文件中UE在收到MIB后执行的是RA，而非SR。因此，该特征未被公开。 |
| **技术特征N**：还包括：在所述第二预定时间段内未接收到所述MIB的情况下，发起无线链路失败(RLF)过程。 《未公开》 | 无对应内容。 | 对比文件没有提及RLF过程，也没有将RLF与MIB接收失败相关联。因此，该特征未被公开。 |
| **技术特征O**：其中，所述预定时间段是至少部分地基于预定数量的长期演进(LTE)帧的。 《未公开》 | 无对应内容。 | 对比文件虽然提到了LTE帧（10ms）和PBCH TTI（40ms，即4个帧），但并未将这些时间长度描述为UE为“延迟调度请求传输”而设置的“预定时间段”。因此，该特征未被公开。 |
| **技术特征P**：包括：用于确定已经发生从第一基站到第二基站的切换的单元 《隐含公开》 | [0056]-[0057] 描述了UE接收RRCConnectionReconfiguration消息以执行切换。 | 对比文件直接公开了“确定切换发生”的功能（特征A）。对于本领域技术人员而言，实现该功能必然需要相应的处理单元、模块或电路（例如，用于接收和处理RRC信令的单元）。因此，该装置特征被对比文件隐含公开。 |
| **技术特征Q**：用于至少部分地基于确定在所述切换之后在所述装置处没有从所述第二基站接收到主信息块(MIB)，将对调度请求到所述第二基站的传输延迟预定时间段的单元。 《未公开》 | 无对应内容。 | 如特征B所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征R**：其中，所述用于延迟对所述调度请求的所述传输的单元延迟所述调度请求，直到已经从所述第二基站接收到所述MIB为止。 《未公开》 | 无对应内容。 | 如特征C、D所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征S**：还包括：用于确定在已经发生所述切换之前已经接收到系统信息块(SIB)的单元。 《未公开》 | 无对应内容。 | 如特征E所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征T**：其中，所述预定时间段是至少部分地基于以下各项的：通过从所述第二基站接收的所述MIB来对上行链路定时的期望获取或期望导出。 《未公开》 | 无对应内容。 | 如特征F所述，对比文件未公开该特征。因此，包含该特征的单元也未被公开。 |
| **技术特征U**：还包括：用于确定要在所述切换之后向所述第二基站发送数据的单元 《未公开》 | 无对应内容。 | 如特征G所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征V**：用于基于确定在所述切换之后还没有从所述第二基站接收到所述MIB，确定所述MIB不存在的单元 《隐含公开》 | [0062] 图4流程；[0072] 图5流程（见特征H引用）。 | 对比文件隐含公开了“基于确定未收到MIB而确定MIB不存在”的功能（特征H）。对于本领域技术人员而言，实现该判断功能必然需要相应的处理单元、模块或电路。因此，该装置特征被对比文件隐含公开。 |
| **技术特征W**：用于将对所述调度请求的所述传输延迟所述预定时间段的单元。 《未公开》 | 无对应内容。 | 如特征I所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征X**：还包括：用于至少部分地基于确定在所述切换之后已经接收到所述MIB，向所述第二基站发送所述调度请求的单元。 《未公开》 | 无对应内容。 | 如特征J所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征Y**：还包括：用于在所述预定时间段到期之后，确定是否已经接收到所述MIB的单元 《未公开》 | 无对应内容。 | 如特征K所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
| **技术特征Z**：用于响应于确定来自所述第二基站的所述MIB继续不存在，将对所述调度请求的所述传输进一步延迟第二预定时间段的单元。 《未公开》 | 无对应内容。 | 如特征L所述，对比文件未公开该功能。因此，实现该功能的单元也未被公开。 |
<<<A>>><<<h>>><<<p>>><<<v>>>