对比文件名称：发明申请_US20170134148A1 DISCOVERY REFERENCE SIGNAL CONFIGURATION AND SCRAMBLING IN LICENSED-ASSISTED ACCESS
目标专利名称：在多子帧DRS中子帧的CSI‑RS加扰
本次调用的模型名称：DeepSeek-R1
### 特征比对表格
| 技术特征描述及公开性判断结果 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**《隐含公开》 | [0033] “在LAA背景下，DRS可以周期性地或非周期性地传输，无论是根据设计还是基于在免授权频谱中传输的CCA或LBT限制。” <br> [0086] “为了降低UE 402的实现复杂性并提高可靠性，对于DMTC内的DRS中的CRS和CSI‑RS传输，可以采用以下加扰方案中的至少一种：在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中使用SF#0加扰，在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中使用SF#5加扰...” | 该特征要求一种“配置在共享的通信介质上的信道状态信息参考信号CSI‑RS的方法”。对比文件整体技术方案涉及在LAA（一种共享通信介质）中配置和发送发现参考信号（DRS），而DRS包含CSI-RS（参见[0031]、[0062]、[0082]）。对比文件[0086]明确描述了为CSI-RS配置加扰方案的规则，以在共享介质（免授权频谱）上实现可靠的测量。因此，对比文件隐含公开了一种在共享通信介质上为CSI-RS配置加扰规则的方法，这与目标专利中为解决CSI-RS加扰问题而提供的方法属于相同类型。 |
| **技术特征B**《隐含公开》 | [0033] “在LAA背景下，DRS可以周期性地或非周期性地传输，无论是根据设计还是基于在免授权频谱中传输的CCA或LBT限制。” <br> [0070] “...UE 402可以基于包含DRS的子帧相对于发现窗口的相对位置来选择特定的加扰序列。” <br> [0084] “在LAA中，DRS可以在DMTC内‘浮动’，即它可能发生在DMTC内的几个子帧候选位置之一。” <br> [0086] “...使用SF#0加扰在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中...使用SF#5加扰在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中...” | 该特征包括执行CCA协议以确定是否在DMTC窗内开始传输，并且无线帧包含第一子帧块（SF0-4）和第二子帧块（SF5-9）。对比文件[0033]指出DRS传输受CCA/LBT限制，隐含了执行CCA以获取信道接入的必要性。对比文件[0084]和[0086]明确将DMTC窗内的子帧划分为两组（SF0-4和SF5-9），这与“第一子帧块和第二子帧块”的划分相对应。因此，本领域技术人员可以合理推断出，在LAA系统中，需要在DMTC窗开始前执行CCA来确定是否可以传输，且窗内子帧被如此划分。 |
| **技术特征C**《隐含公开》 | [0033] “...发现窗口可以由DRS测量时序配置（DMTC）定义...邻居小区可以在发现窗口的一个或多个特定子帧中传输DRS...” <br> [0062] “在传输DRS的子帧中，资源网格370还可以包括用于DRS的资源元素。例如...CSI-RS (C) 380。” <br> [0084] “在LAA中，DRS可以在DMTC内‘浮动’，即它可能发生在DMTC内的几个子帧候选位置之一。” | 该特征要求发送在DMTC窗内的多子帧DRS，该DRS包括多个DRS子帧，每个子帧包含多个符号。对比文件[0033]和[0084]明确指出DRS在DMTC窗口内传输，并且可以占据多个子帧候选位置。对比文件[0062]的图3B及其描述展示了包含CSI-RS资源的DRS子帧结构，该结构必然包含多个OFDM符号（如资源网格370所示）。虽然“多子帧DRS”这一特定术语未被使用，但对比文件描述了在DMTC窗内发送包含参考信号（如CSI-RS）的DRS，且DRS可能占据窗内多个子帧位置。本领域技术人员可以理解，为实现可靠的发现和测量，发送跨越多个子帧的DRS是隐含的、合理的扩展。 |
| **技术特征D**《隐含公开》 | [0086] “为了降低UE 402的实现复杂性并提高可靠性，对于DMTC内的DRS中的CRS和CSI‑RS传输，可以采用以下加扰方案中的至少一种：在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中使用SF#0加扰，在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中使用SF#5加扰...” <br> [0087] “这样的加扰方案确保，无论UE 402在DMTC内检测到（同步或异步）邻居小区的PSS/SSS传输，该子帧中CRS和CSI‑RS序列的加扰都可以通过确定PSS/SSS传输是基于前导码（SF#0）还是基于中导码（SF#5）来确定。” | 该特征要求根据CSI-RS加扰规则对多子帧DRS中的第一和第二DRS子帧中的CSI-RS进行加扰。对比文件[0086]明确提出了针对DMTC内不同子帧组的CSI-RS加扰规则（SF#0加扰用于子帧0-4，SF#5加扰用于子帧5-9）。[0087]进一步解释，该规则使得UE能够基于检测到的PSS/SSS类型（对应子帧组）来确定CSI-RS的加扰。这意味着基站侧必然按照此规则对CSI-RS进行加扰，以便UE正确解扰。虽然未明确提及“第一DRS子帧”和“第二DRS子帧”的命名，但加扰规则应用于DMTC窗内传输DRS的各个子帧（包括第一个和后续子帧）是隐含的。 |
| **技术特征E**《隐含公开》 | [0086] “为了降低UE 402的实现复杂性并提高可靠性，对于DMTC内的DRS中的CRS和CSI‑RS传输，可以采用以下加扰方案中的至少一种：在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中使用SF#0加扰...” <br> [0087] “...该子帧中CRS和CSI‑RS序列的加扰都可以通过确定PSS/SSS传输是基于前导码（SF#0）还是基于中导码（SF#5）来确定。” | 该特征限定了第一DRS子帧位于第一子帧块（SF0-4）中，并基于此，第二DRS子帧中的CSI-RS使用针对第一子帧块初始块（即SF0）定义的加扰。对比文件[0086]的规则明确指出，如果DRS传输发生在子帧0-4（即第一子帧块）中的任何子帧，则使用SF#0的加扰。这意味着，无论DRS具体从该块中的哪个子帧开始（例如作为“第一DRS子帧”），该次DRS传输中所有子帧（可视为包括后续的“第二DRS子帧”）的CSI-RS都使用SF#0加扰。这正是基于第一DRS子帧所属块来确定后续子帧加扰方式的逻辑。因此，该技术特征被对比文件隐含公开。 |
| **技术特征F**《隐含公开》 | [0086] “...在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中使用SF#5加扰...” <br> [0087] “...该子帧中CRS和CSI‑RS序列的加扰都可以通过确定PSS/SSS传输是基于前导码（SF#0）还是基于中导码（SF#5）来确定。” | 该特征限定了第一DRS子帧位于第二子帧块（SF5-9）中，并基于此，第二DRS子帧中的CSI-RS使用针对第二子帧块初始块（即SF5）定义的加扰。对比文件[0086]的规则明确指出，如果DRS传输发生在子帧5-9（即第二子帧块）中的任何子帧，则使用SF#5的加扰。这意味着，无论DRS具体从该块中的哪个子帧开始，该次DRS传输中所有子帧的CSI-RS都使用SF#5加扰。这与特征E的逻辑完全对称，因此也被对比文件隐含公开。 |
| **技术特征G**《直接公开》 | [0086] “为了降低UE 402的实现复杂性并提高可靠性，对于DMTC内的DRS中的CRS和CSI‑RS传输，可以采用以下加扰方案中的至少一种：在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中使用SF#0加扰，在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中使用SF#5加扰...” | 该特征定义了“固定的CSI-RS加扰规则”，即对第一和第二DRS子帧两者使用相同的加扰。对比文件[0086]明确公开了具体的加扰方案：对于落在子帧0-4组内的任何DRS传输，统一使用SF#0加扰；对于落在子帧5-9组内的任何DRS传输，统一使用SF#5加扰。这正是一种“固定的”规则，在该规则下，一次DRS传输中的所有子帧（包括第一个和第二个）都使用相同的加扰序列（SF#0或SF#5）。这与目标专利中描述的“固定的CSI-RS加扰规则”作用完全相同，都是为了简化UE检测复杂度。因此，该技术特征被对比文件直接公开。 |
| **技术特征H**《隐含公开》 | [0086] “为了降低UE 402的实现复杂性并提高可靠性，对于DMTC内的DRS中的CRS和CSI‑RS传输，可以采用以下加扰方案中的至少一种：在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中使用SF#0加扰...” | 该特征是对特征G和E的组合限定，即基于固定的规则且第一DRS子帧在第一子帧块中时，第一和第二DRS子帧的CSI-RS均使用针对第一子帧块初始块（SF0）的加扰。对比文件[0086]公开的固定规则已经直接指明了在子帧0-4中使用SF#0加扰。应用此规则，必然意味着当DRS传输始于该块时（第一DRS子帧），其自身以及后续子帧（第二DRS子帧）的CSI-RS都使用SF#0加扰。这是从已公开的固定规则中直接、毫无疑义地推导出的具体操作方式。因此，该技术特征被对比文件隐含公开。 |
| **技术特征I**《隐含公开》 | [0086] “...在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中使用SF#5加扰...” | 该特征是对特征G和F的组合限定，即基于固定的规则且第一DRS子帧在第二子帧块中时，第一和第二DRS子帧的CSI-RS均使用针对第二子帧块初始块（SF5）的加扰。对比文件[0086]公开的固定规则已经直接指明了在子帧5-9中使用SF#5加扰。应用此规则，必然意味着当DRS传输始于该块时（第一DRS子帧），其自身以及后续子帧（第二DRS子帧）的CSI-RS都使用SF#5加扰。这是从已公开的固定规则中直接、毫无疑义地推导出的具体操作方式。因此，该技术特征被对比文件隐含公开。 |
| **技术特征J**《未公开》 | 对比文件中未发现相关内容。 | 该特征描述了一种特定的加扰规则：当第一DRS子帧在第一子帧块的初始块（SF0）上发送，且第二DRS子帧在同一子帧块的第二块（如SF1）上发送时，对第二DRS子帧使用针对该第二块（SF1）定义的加扰。这与对比文件[0086]公开的固定规则（在子帧0-4中均使用SF0加扰）相矛盾。对比文件旨在通过固定加扰来简化UE处理，并未提及这种根据DRS内子帧的实际位置动态改变加扰的方案。因此，该技术特征既未被直接公开，也未被隐含公开。 |
| **技术特征K**《未公开》 | 对比文件中未发现相关内容。 | 该特征描述了一种与特征J对称的规则：当第一DRS子帧在第二子帧块的初始块（SF5）上发送，且第二DRS子帧在同一子帧块的第二块（如SF6）上发送时，对第二DRS子帧使用针对该第二块（SF6）定义的加扰。这与对比文件[0086]公开的固定规则（在子帧5-9中均使用SF5加扰）相矛盾。对比文件未提及这种根据实际子帧位置改变加扰的方案。因此，该技术特征既未被直接公开，也未被隐含公开。 |
| **技术特征L**《未公开》 | 对比文件中未发现相关内容。 | 该特征描述了一种“交叉加扰”规则：当第一和第二DRS子帧均位于第一子帧块（SF0-4）时，对第二DRS子帧使用针对第二子帧块初始块（SF5）定义的加扰。对比文件[0086]公开的规则明确将SF0加扰与子帧0-4绑定，将SF5加扰与子帧5-9绑定，并未提出或暗示这种跨子帧块使用加扰的方案。目标专利说明书中提出此方案是为了在某些LBT场景下确保至少一个子帧的加扰对齐，但对比文件完全未涉及此构思。因此，该技术特征未被公开。 |
| **技术特征M**《未公开》 | 对比文件中未发现相关内容。 | 该特征描述了一种与特征L对称的“交叉加扰”规则：当第一和第二DRS子帧均位于第二子帧块（SF5-9）时，对第二DRS子帧使用针对第一子帧块初始块（SF0）定义的加扰。与特征L同理，这与对比文件公开的固定绑定规则相悖，且对比文件未提及任何交叉加扰的概念。因此，该技术特征未被公开。 |
| **技术特征N**《隐含公开》 | [0033] “...在LAA背景下，DRS可以周期性地或非周期性地传输，无论是根据设计还是基于在免授权频谱中传输的CCA或**对话前监听（LBT）**限制。” <br> [0092] “...配置为周期性CSI-RS传输一部分的CSI-RS可能会周期性出现，但需服从**对话前监听（LBT）**。” | 该特征限定CCA协议是LBT类别4（Cat 4）。对比文件多次提及LAA操作中需要使用LBT（对话前监听）协议，这是未授权频谱接入的核心机制（例如[0033], [0092]）。LBT Cat 4是LAA标准中定义的、带有随机回退的CCA协议，是本领域在讨论LAA时公认的标准LBT机制。虽然对比文件未明确写出“类别4”，但本领域技术人员在阅读对比文件提及的LAA和LBT时，能够毫无疑义地理解其所指的就是包括Cat 4在内的标准LBT程序。因此，该技术特征被对比文件隐含公开。 |
| **技术特征O**《隐含公开》 | [0086] “为了降低UE 402的实现复杂性并提高可靠性，对于DMTC内的DRS中的CRS和CSI‑RS传输，可以采用以下加扰方案中的至少一种：在实际子帧SF#0、SF#1、SF#2、SF#3和SF#4中使用SF#0加扰，在实际子帧SF#5、SF#6、SF#7、SF#8和SF#9中使用SF#5加扰...” | 该特征概括了CSI-RS加扰规则的核心：根据第一DRS子帧所属的子帧块，决定对第二DRS子帧中的CSI-RS使用不同的加扰（第一加扰SF#0或第二加扰SF#5）。对比文件[0086]明确公开的规则正是：若传输发生在子帧0-4（第一子帧块），则使用SF#0加扰；若发生在子帧5-9（第二子帧块），则使用SF#5加扰。这直接体现了“如果属于第一块则用第一加扰，如果属于第二块则用不同的第二加扰”的逻辑。该规则应用于DRS传输中的所有子帧，自然包括第二DRS子帧。因此，该技术特征被对比文件隐含公开。 |
<<<G>>><<<a>>><<<b>>><<<c>>><<<d>>><<<e>>><<<f>>><<<h>>><<<i>>><<<n>>><<<o>>>