**对比文件的名称：** 2003-12-25_US2003235212A_发明申请_US20030235212A1 Method for synchronizing a START value for security in a wireless communication network
**目标专利的名称：** 无线通讯系统分组数据汇聚协议层数据保密的方法及装置 CN101420424B
**本次调用的模型名称：** AI Assistant (基于专利评估场景的深度分析模型)
---
| 技术特征描述及公开性判断结果 | 对比文件原文引用（翻译） | 公开性论述 |
| **技术特征A：** 于上述客户端由来源基地台交递至目地基地台时，接收从下层传递上来的封包。<br>**未公开** | 对比文件[0031]：“The UE 100 receives the Radio Bearer Setup message 126”（UE 100 接收无线承载建立消息 126）。该消息属于RRC层信令，并非从下层（如RLC层）传递上来的数据封包。对比文件其他部分也未描述在SRNS重定位（相当于基地台交递）时从下层接收PDCP数据单元的过程。 | 对比文件涉及SRNS重定位过程中UE接收RRC重配置消息，但未公开在交递时从下层（例如RLC层或MAC层）接收数据封包（例如PDCP PDU）的步骤。目标专利中的“下层”指PDCP层之下的协议层，而对比文件无相关教导。本领域技术人员无法直接从对比文件毫无疑义地得出该特征，亦无法合理推断出该具体接收过程。因此未被公开（包括直接和隐含）。 |
| **技术特征B：** 该封包系于基地台交递发生前，由该来源基地台传送至用户端。<br>**未公开** | 对比文件[0012]提及SRNS重定位过程，但未记载在交递发生前有封包从来源基地台传送至用户端并在交递时被处理。对比文件[0031]描述UE接收重配置消息作为交递指令，但该消息并非交递前传送的数据封包。 | 对比文件未涉及任何关于“交递发生前由来源基地台传送至用户端的封包”的缓冲或后续处理。整个描述集中在信令交互和HFN同步，缺乏对交递前已传送数据封包的处理机制。因此未被公开。 |
| **技术特征C：** 使用对应于上述来源基地台的保密参数集，解密从下层传递上来的封包。<br>**未公开** | 对比文件[0013]：“The UE 40 re-establishes the RLC entity 76 of RB2 48, and re-initializes the rHFN 76r and the tHFN 76t for RB2 48. The new values for the rHFN and tHFN 76t for RB2 48 are given by the equation: MAX(rHFN of RB2, tHFN of RB2)+1”。（UE 40 重建RB2 48的RLC实体，并重新初始化rHFN 76r和tHFN 76t。新值由等式 MAX(rHFN of RB2, tHFN of RB2)+1给出）。对比文件使用新计算的START值初始化HFN，而非使用对应于来源基地台的原有保密参数进行解密。 | 对比文件在SRNS重定位时采用重新计算并初始化HFN的方式，这实质上是使用对应于目标基地台（新SRNS）的保密参数，而没有使用对应来源基地台的保密参数集对已有封包进行解密。对比文件缺少“使用来源基地台保密参数解密”这一步骤，且教导了相反的操作（重置为与新SRNS同步的值）。因此未被公开。 |
| **技术特征D：** 于完成对所有从下层传递上来的封包的解密时，重设该保密参数。<br>**未公开** | 对比文件[0031]：“In response to this acknowledgement, the RRC layer 80 of the UE 100 re-establishes all remaining RBs 208 (except RB2, RB0, and the new RB 202), utilizes the START list 204 to set the HFNs ...”（响应于该确认，UE 100的RRC层80重建所有剩余RB（除了RB2、RB0和新RB202），利用START列表204设置HFN...）。重置动作在收到确认后发生，但与解密已完成的条件无关。对比文件中并无从下层接收封包并解密的过程。 | 对比文件的重设（初始化HFN）是在信令确认后执行的，并未与“完成对所有从下层传递上来的封包的解密”这一条件相关联。目标专利强调先解密已有封包再重置，对比文件则没有解密步骤，其重置是为了与新SRNS同步，并非在解密完成后进行。因此未被公开。 |
| **技术特征E：** 从上述来源基地台所接收的分组数据汇聚协议封包对应于无线链路控制层的非确认模式。<br>**未公开** | 对比文件[0009]：“In AM transmissions, ... n is 12. In other transport modes, n is 7.”（在确认模式传输中，n为12。在其他传输模式中，n为7）。该描述仅区分了RLC传输模式，但未指明PDCP封包与RLC非确认模式之间的对应关系，也未在SRNS重定位场景下涉及任何模式选择。 | 对比文件虽然提及RLC存在确认模式和其他模式，但未将PDCP层封包与特定的RLC模式（尤其是非确认模式）相关联。目标专利明确指出来自于来源基地台的PDCP封包是在RLC非确认模式下传输的，对比文件没有任何关于PDCP使用UM模式的记载或暗示。因此未被公开。 |
| **技术特征F：** 从上述来源基地台所接收的分组数据汇聚协议封包用于使用者平面数据传输。<br>**隐含公开** | 对比文件[0005]原文：“U-plane 94 handles user data transport between the UE 40 and the UTRAN 20. The PDCP layer 70 provides header compression for Service Data Units (SDUs) received from the U-plane.” 译文：“用户平面94处理UE40和UTRAN20之间的用户数据传输。PDCP层70为从用户平面接收的服务数据单元（SDU）提供标头压缩。” 此外，对比文件[0013]和[0031]涉及的SRNS重定位过程中重建的RB包括用户面RB（除信令RB外）。 | 对比文件明确公开了PDCP层用于处理用户平面（使用者平面）数据。在SRNS重定位的连接场景下，从来源基地台传送至UE的封包（通过用户面RB）必然属于使用者平面数据传输，本领域技术人员结合对比文件关于PDCP处理U-plane数据的普遍教导以及重定位过程中用户面RB重建的说明，可以合理推断出从来源基地台所接收的PDCP封包的用途是使用者平面数据传输。该推断具有合理的技术基础，因此技术特征F被对比文件隐含公开。 |
| **技术特征G：** 上述保密参数集包含预期分组数据汇聚协议接收序号以及接收端超框数。<br>**未公开** | 对比文件[0009]：“The HFNs 76r, 76t are used as the high-order bits of the COUNT-C value, and the sequence number 53 of the PDU 50 is used as the low order bits.”（HFN 76r, 76t用作COUNT-C值的高位比特，PDU 50的序列号53用作低位比特）。这些参数属于RLC层，而非PDCP层。对比文件未提及PDCP层的预期接收序号（Next_PDCP_RX_SN）和接收端超框数（RX_HFN）。 | 目标专利的保密参数集是PDCP层特有的，包括Next_PDCP_RX_SN和RX_HFN。对比文件涉及的是RLC层的HFN和序列号，虽然概念类似但属于不同协议层，且对比文件没有将RLC层参数扩展到PDCP层的任何教导。因此未被公开。 |
| **技术特征H：** 重设该保密参数就是将该保密参数初始化为零。<br>**未公开** | 对比文件[0013]：“The new values for the rHFN and tHFN for RB2 48 are given by the equation: MAX(rHFN of RB2, tHFN of RB2)+1”。（RB2 48的rHFN和tHFN新值由等式MAX(rHFN of RB2, tHFN of RB2)+1给出）。此外，其他RB的重设使用START列表中的值，这些值均非零。 | 对比文件中重设保密参数（HFN）时，采用MAX(rHFN, tHFN)+1或从START列表取值，所得数值均大于或等于已有值，绝非初始化为零。目标专利的“初始化为零”是背景技术中描述的已知问题，对比文件完全没有采用零初始化。因此未被公开。 |
---
<<<f>>>