**对比文件名称**：发明申请_US20210007146A1 METHOD OF RANDOM ACCESS PROCEDURE FOR SUPPORTING LARGE RANDOM ACCESS RESOINSE (RAR) WINDOW SIZE
**目标专利名称**：随机接入响应类型区分
**本次调用模型名称**：DeepSeek
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：一种由用户设备(UE)执行的无线通信方法<br>**公开性判断**：《直接公开》 | [0025] "So an enhanced method for transmitting and receiving frame information in RAR is needed."<br>[0030] "In accordance with an aspect of the disclosure, a method performed by a terminal for handling listen before talk (LBT) failure in a wireless communication system is provided."<br>[0257] "In the disclosure, UE/gNB transmits/receives RAR MAC PDU..."<br>[0449] "In the 5G wireless communication system, RA is supported. RA is used to achieve UL time synchronization. RA is used during initial access, handover, RRC connection re-establishment procedure, scheduling request transmission, SCG addition/modification, beam failure recovery and data or control information transmission in UL by non-synchronized UE in RRC CONNECTED state."<br>[0473] "Method 1:"<br>[0474] "FIG. 25 shows a method of the UE for performing the RA procedure according to an embodiment of the disclosure."<br>[0475] "Referring to FIG. 25, UE transmits RA preamble (also referred as Msg1) and then waits for RAR in the RAR window at operation 2510." | **直接公开**。对比文件通篇描述的是由UE（终端）执行的无线通信方法，特别是关于随机接入（RA）过程的方法。说明书[0025]、[0030]等段落明确提出了UE执行方法的需求和具体实施例。例如，[0257]指出“UE/gNB transmits/receives RAR MAC PDU”，[0449]详细说明了UE在多种场景下执行随机接入过程，而[0473]之后的具体方法描述（如方法1、图25及操作2510）更是直接、明确地公开了由UE执行的、包括发送前导码和等待RAR在内的无线通信方法步骤。这与目标专利中“由用户设备(UE)执行的无线通信方法”这一上位概念完全一致。在对比文件的整体技术方案中，该方法用于解决RAR窗口较大时的接入和响应问题，与目标专利中为解决RAR类型区分问题而执行的方法同属于UE侧的无线通信控制方法范畴。 |
| **技术特征B**：接收指示与随机接入响应(RAR)类型相关联的传输参数的配置信息，其中所述传输参数包括物理下行链路控制信道(PDCCH)通信中携带的下行链路控制信息(DCI)的循环冗余校验(CRC)掩码<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件未提及“RAR类型”、“与RAR类型相关联的传输参数”的概念，也未提及使用“DCI的CRC掩码”作为用于区分RAR类型的传输参数。 | **未公开**。目标专利的技术特征B的核心在于：1) 配置信息指示“与RAR类型相关联的传输参数”；2) 该传输参数特指“PDCCH通信中携带的DCI的CRC掩码”。对比文件虽然提到了配置RAR窗口大小（例如[0449]）、以及在某些情况下DCI中携带帧信息（例如[0469]“frame information in DCI of received PDCCH”），但从未将“CRC掩码”作为一种可配置的、用于区分不同“RAR类型”的“传输参数”进行描述或暗示。对比文件中DCI携带的帧信息（如SFN的LSB）是用于解决RAR窗口扩展导致的RA-RNTI模糊性问题（见[0468]-[0469]），其作用与目标专利中通过CRC掩码来区分并发传输的不同类型RAR以节省UE盲解码资源的作用完全不同。本领域技术人员无法从对比文件中直接或通过合理推理得到“使用CRC掩码作为与RAR类型相关联的传输参数”这一技术手段。 |
| **技术特征C**：发送与所述RAR类型相关联的随机接入消息<br>**公开性判断**：《隐含公开》 | [0449] "RA is used during initial access, handover, RRC connection re-establishment procedure, scheduling request transmission, SCG addition/modification, beam failure recovery and data or control information transmission in UL by non-synchronized UE in RRC CONNECTED state."<br>[0460] "Contention based RA (CBRA): ... In this type of RA, UE first transmits RA preamble (also referred as message 1 (Msg1)) ..."<br>[0462] "Contention free RA (CFRA): ... UE transmits the dedicated RA preamble."<br>[0464] "2 step CBRA: In the first step, UE transmits RA preamble on PRACH and a payload on PUSCH. The RA preamble and payload transmission is also referred as message A (MsgA)."<br>[0475] "Referring to FIG. 25, UE transmits RA preamble (also referred as Msg1) and then waits for RAR in the RAR window at operation 2510." | **隐含公开**。对比文件多次明确公开了UE发送随机接入消息（如前导码Msg1、MsgA）的步骤（如[0460], [0462], [0464], [0475]）。虽然对比文件没有明确使用“与RAR类型相关联”这一术语，但其描述的随机接入过程本身就对应着不同的场景和模式（如基于竞争的CBRA、基于非竞争的CFRA、2步RA），这些不同的场景/模式本质上可能导致基站发送不同特性或内容的RAR。例如，CBRA和CFRA的后续处理流程不同；2步RA的MsgB与4步RA的Msg2内容也可能不同。本领域技术人员知晓，随机接入消息（如前导码的选择、MsgA的发送）隐含着后续期望收到的RAR的某些特性。因此，可以合理推断，UE发送的随机接入消息是与某种特定“RAR类型”或“RAR特性”相关联的。此处的“RAR类型”可被宽泛地理解为与不同随机接入场景相对应的RAR。 |
| **技术特征D**：在发送所述随机接入消息之后，使用传输参数来获得物理下行链路控制信道(PDCCH)通信<br>**公开性判断**：《隐含公开》 | [0460] "... and then waits for RAR in the RAR window."<br>[0469] "RAR is considered successful, if UE receives PDCCH addressed to RA-RNTI and frame information in DCI of received PDCCH matches frame information ..."<br>[0475] "UE transmits RA preamble ... and then waits for RAR in the RAR window at operation 2510."<br>[0478] "UE monitors PDCCH addressed to RA-RNTI in RAR window at operation 2530."<br>[0492] "UE monitors PDCCH addressed to RA-RNTI in RAR window at operation 2820." | **隐含公开**。对比文件明确公开了UE在发送随机接入消息（如前导码）后，在RAR窗口内监视（即尝试获得）PDCCH通信（寻址到RA-RNTI）的步骤（如[0478], [0492]）。虽然对比文件没有明确提及“使用传输参数”来获得PDCCH，但其描述了在RAR窗口>10ms时，UE需要检查接收到的PDCCH的DCI中携带的“帧信息”（frame information，如SFN的LSB）是否匹配（见[0469]）。这个“帧信息”可以视为一种用于验证PDCCH是否属于当前RAR窗口的“参数”。UE在解调、解码PDCCH时，必然需要使用一系列参数（如RA-RNTI、DCI格式、加扰/CRC等），其中“帧信息匹配”是成功“获得”有效PDCCH（即调度了属于本UE的RAR的PDCCH）的一个判断条件。因此，可以合理推断UE在获得PDCCH的过程中使用了相关的参数（包括隐含的用于验证的“帧信息”参数）。 |
| **技术特征E**：其中所述PDCCH通信与具有随机接入响应(RAR)类型的随机接入响应相关联，并且其中所述传输参数用于在不同RAR类型之间进行区分。<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件未建立“RAR类型”的概念，也未描述“传输参数用于在不同RAR类型之间进行区分”的技术构思。对比文件中DCI携带的“帧信息”用于区分不同RAR窗口（或不同PRACH时机）的RAR，以防止RA-RNTI歧义（见[0468]-[0469]），而不是用于区分基于不同随机接入模式、UE能力、优先级等定义的“RAR类型”。 | **未公开**。目标专利的技术特征E明确了两个要点：1) PDCCH与特定“RAR类型”的RAR相关联；2) 传输参数的核心作用是在“不同RAR类型之间进行区分”。对比文件完全没有涉及“RAR类型”这一分类概念。其技术问题在于大RAR窗口导致的RA-RNTI模糊性，解决方案是通过DCI中的帧信息来标识RAR所属的无线帧，从而区分来自不同时间（不同PRACH时机）但使用相同RA-RNTI的RAR。这与目标专利中为了解决并发传输的不同类型RAR（如2步/4步、不同优先级）的区分问题，而使用传输参数（如CRC掩码）在PDCCH级别进行区分的发明构思有本质区别。本领域技术人员无法从对比文件中推导出“使用传输参数区分不同RAR类型”的技术手段。 |
| **技术特征F**：还包括至少部分地基于是否使用所述传输参数成功地获得所述PDCCH通信而获得或制止获得由所述PDCCH通信调度的物理下行链路共享信道(PDSCH)通信，其中获得或制止获得所述PDSCH通信包括：如果使用所述传输参数成功接收到所述PDCCH通信，则获得所述PDSCH通信；或者如果使用所述传输参数没有成功接收到所述PDCCH通信，则制止获得所述PDSCH通信。<br>**公开性判断**：《隐含公开》 | [0469] "RAR is considered successful if UE receives PDCCH addressed to RA-RNTI and frame information in DCI of received PDCCH matches frame information corresponding to the SFN in which RA preamble is transmitted and successfully decoded TB scheduled by this PDCCH includes RAPID that matches the RA preamble index of transmitted RA preamble."<br>[0478] "UE monitors PDCCH addressed to RA-RNTI in RAR window at operation 2530."<br>[0479] "RAR is considered successfully received if UE receives PDCCH addressed to RA-RNTI and frame information in DCI of received PDCCH matches frame information ... and successfully decoded TB scheduled by this PDCCH includes RAPID ..." | **隐含公开**。对比文件描述了UE成功接收RAR的条件：必须成功接收PDCCH（寻址到RA-RNTI），并且其DCI中的帧信息匹配，然后才会去解码该PDCCH调度的TB（即PDSCH），并在TB中找到匹配的RAPID（见[0469], [0479]）。这一逻辑过程隐含了：如果PDCCH接收失败（例如未检测到、解码失败），或者DCI中的帧信息不匹配，UE就不会去处理（即制止获得）该PDCCH所调度的PDSCH TB。虽然对比文件没有明确使用“制止获得”这个词，但“只有在PDCCH条件满足后才去解码PDSCH”是通信系统中的常规操作逻辑。这里的“帧信息匹配”可以类比为目标专利中“使用传输参数成功接收PDCCH”的一个判断环节（尽管对比文件的参数目的不同）。因此，可以合理推断出对比文件隐含公开了基于PDCCH接收的成功与否来决定是否获得其调度的PDSCH通信这一基本操作原则。 |
| **技术特征G**：其中不同的RAR类型与不同的随机接入模式、不同的UE能力、不同的优先级、不同长度的RAR窗口或其组合中的至少一个相关联。<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件提到了不同的随机接入模式（如CBRA, CFRA, 2-step RA，见[0460], [0462], [0464]）和可配置的RAR窗口大小（如[0449]），但从未将这些不同的模式或配置与“不同的RAR类型”这个概念关联起来，也未提及RAR类型与UE能力、优先级相关联。 | **未公开**。目标专利的技术特征G明确限定了“RAR类型”的具体内涵，即其与随机接入模式、UE能力、优先级、RAR窗口长度等特征相关联。对比文件虽然描述了不同的随机接入过程和可变的RAR窗口，但始终没有提出一个统一的“RAR类型”概念来统领和区分这些特征，更没有揭示这些特征与某种“RAR类型”之间存在关联关系。对比文件中扩展RAR窗口是为了解决非授权频谱上的LBT问题（见[0468]），而非为了区分服务于不同业务或UE的RAR类型。因此，该技术特征未被对比文件公开。 |
| **技术特征H**：其中所述RAR是基于所述随机接入消息使用不同的RAR类型区分方案并发发送的具有不同RAR类型的多个RAR之一。<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件没有描述基站“并发发送”具有不同“类型”的多个RAR的场景。其描述的RAR都在同一个RAR MAC PDU中（见[0459]），解决的是时序上的歧义，而非类型上的并发区分。 | **未公开**。该特征描述了目标专利要解决的核心场景之一：多个不同类型的RAR被并发发送。对比文件的技术问题源于时间上的延伸（大RAR窗口），导致不同时间发送的相同RA-RNTI的RAR可能被混淆。其方案是加入时间标识（帧信息）来区分它们。这与目标专利中针对“同时”发送的、需要从“类型”上区分的多个RAR场景完全不同。对比文件未提及，也无法隐含出这种“并发发送不同RAR类型”的技术情境。 |
| **技术特征I**：其中使用所述传输参数来获得所述PDCCH通信包括使用CRC掩码来对所述PDCCH通信执行CRC。<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件未提及使用CRC掩码来获得（解码/验证）PDCCH通信。 | **未公开**。该技术特征是非常具体的手段限定：使用CRC掩码对PDCCH执行CRC校验。对比文件中完全没有涉及“CRC掩码”这一概念，无论是用于区分RAR类型还是其他目的。PDCCH的CRC校验通常使用RNTI加扰，但“CRC掩码”作为一种特定的、可配置的区分手段，在对比文件中没有任何记载或暗示。 |
| **技术特征J**：还包括接收配置信息，所述配置信息指示用于调度具有第一RAR类型的RAR的PDCCH通信的第一组循环冗余校验(CRC)掩码，以及用于调度具有第二RAR类型的RAR的PDCCH通信的第二组CRC掩码。<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件未提及通过配置信息指示多组CRC掩码，也未提及这些掩码与RAR类型的对应关系。 | **未公开**。该特征是技术特征B和I的进一步具体化，涉及通过配置信息明确指示多组与不同RAR类型绑定的CRC掩码。对比文件完全没有涉及“CRC掩码”的概念，更谈不上通过配置来指示多组这样的掩码用于区分类型。该特征未被公开。 |
| **技术特征K**：其中所述第一组CRC掩码和所述第二组CRC掩码是互斥的。<br>**公开性判断**：《未公开》 | 无直接对应原文。由于对比文件未公开“CRC掩码”及“组”的概念，因此自然也谈不上公开这些组之间的“互斥”关系。 | **未公开**。该特征是技术特征J的从属限定。由于上位特征J未被公开，此从属特征K也未被公开。 |
| **技术特征L**：其中所述传输参数包括与所述PDCCH通信相关联的控制资源集(CORESET)配置、与所述PDCCH通信相关联的搜索空间(SS)配置，或者其组合。<br>**公开性判断**：《直接公开》 | [0455] "A UE monitors a set of PDCCH candidates in the configured monitoring occasions in one or more configured COntrol REsource SETs (CORESETs) according to the corresponding search space configurations."<br>[0457] "Search space configuration includes the identifier of CORESET configuration associated with it. A list of CORESET configurations is signaled by gNB for each configured BWP wherein each CORESET configuration is uniquely identified by an identifier." | **直接公开**。对比文件[0455]和[0457]明确记载了UE根据配置的搜索空间（SS）配置，在配置的控制资源集（CORESET）中监视PDCCH候选。并且明确指出gNB为每个BWP配置了一个CORESET配置列表和搜索空间配置列表。这些“CORESET配置”和“搜索空间配置”正是与PDCCH通信相关联的传输参数，用于定义PDCCH的传输和接收资源。这与目标专利中传输参数包括CORESET配置、SS配置或其组合的内容完全相同。在对比文件中，这些参数用于常规的PDCCH监视，而在目标专利中，这些参数被用于区分RAR类型，但参数本身的含义和内容已被对比文件直接公开。 |
| **技术特征M**：其中使用所述传输参数来获得所述PDCCH通信包括针对与所述RAR类型相关联的所述PDCCH通信，监视根据所述CORESET配置而配置的CORESET或根据所述SS配置而配置的SS中的至少一个。<br>**公开性判断**：《隐含公开》 | [0455] "A UE monitors a set of PDCCH candidates in the configured monitoring occasions in one or more configured COntrol REsource SETs (CORESETs) according to the corresponding search space configurations." | **隐含公开**。对比文件[0455]直接公开了UE根据搜索空间配置，在配置的CORESET中监视PDCCH。虽然对比文件没有明确说这是为了获得“与RAR类型相关联的PDCCH”，但其在描述随机接入过程（如[0478] UE监视寻址到RA-RNTI的PDCCH）时，UE必然需要应用相应的CORESET/SS配置来执行监视。因此，“使用CORESET/SS配置来监视（即获得）PDCCH”这一手段已被直接公开。考虑到技术特征C已论证了随机接入消息可隐含关联某种RAR特性，那么为接收相应RAR而监视的PDCCH也可以隐含为“与RAR类型相关联”。因此，本领域技术人员可以从对比文件公开的“使用配置监视PDCCH”这一通用手段，结合随机接入上下文，合理推断出“针对与RAR类型相关联的PDCCH通信，监视根据配置的CORESET或SS”这一具体应用。 |
| **技术特征N**：还包括接收配置信息，所述配置信息指示用于调度具有第一RAR类型的RAR的PDCCH通信的第一控制资源集(CORESET)配置或第一搜索空间配置，以及用于调度具有第二RAR类型的RAR的第二CORESET配置或第二搜索空间配置。<br>**公开性判断**：《未公开》 | [0457] "A list of CORESET configurations is signaled by gNB for each configured BWP..." 但未提及这些配置与“第一RAR类型”、“第二RAR类型”的对应关系。 | **未公开**。对比文件虽然公开了gNB会信令通知CORESET配置列表（[0457]），但从未将这些不同的配置与不同的“RAR类型”关联起来。目标专利的特征N明确要求配置信息指示的是“用于调度具有特定RAR类型的RAR的PDCCH通信”的特定配置。对比文件中的配置是用于常规的PDCCH监视，而非作为区分RAR类型的标识符。因此，该特征未被公开。 |
| **技术特征O**：其中所述传输参数与用于区分不同RAR类型的传输方案相关联。<br>**公开性判断**：《未公开》 | 无直接对应原文。对比文件未提出“用于区分不同RAR类型的传输方案”这一概念。 | **未公开**。该特征是对传输参数用途的概括性限定，即其关联于一种“区分不同RAR类型的传输方案”。如前所述，对比文件未建立“RAR类型”区分的问题和方案，其传输参数（如CORESET配置）用于常规的PDCCH资源定义，而非用于类型区分。因此，该特征未被公开。 |
<<<A>>><<<L>>>