对比文件名称：2014-04-17_US2014105227A_发明申请_US20140105227A1 DETERMINATIVE SEGMENTATION RESEGMENTATION AND PADDING IN RADIO LINK CONTROL (RLC) SERVICE DATA UNITS (SDU)
目标专利名称：716用于根据SDU分段的PDU格式化的方法、装置和计算机程序产品CN108476197B
模型名称：Claude-4.5-Opus
## 特征比对表格
| 技术特征描述及公开性判断 | 对比文件原文引用 | 公开性论述 |
| **技术特征A**：包括：针对要向接收器实体提供的协议数据单元，首先确定服务数据单元的分段是否要被包括在所述协议数据单元中，并且如果所述服务数据单元的分段要被包括在所述协议数据单元中，则其次确定所述分段相对于所述服务数据单元的位置，所述协议数据单元包括报头部分和数据字段部分 ——《隐含公开》 | [0049] “The RLC sub layer uses dynamic PDU size to build each PDU accordingly to the requested size by the lower layer. Each PDU can have multiple SDU s and segmentation of SDUs and padding are supported.” （RLC子层使用动态PDU大小来根据较低层请求的大小构建每个PDU。每个PDU可以具有多个SDU，并且支持SDU的分段和填充。）[0049] “The Complete/Partial field 346 supports segmentation and concatenation by having a first bit that indicates if the start of the first SDU 354 is segmented while the second bit indicates if the end of the last SDU 356 is segmented.” （完整/部分字段346通过具有第一比特和第二比特来支持分段和级联，第一比特指示第一SDU 354的开始是否被分段，第二比特指示最后SDU 356的结束是否被分段。）[0051] “When the RLC sub layer receives the requested RLC PDU length from the MAC sub layer, the RLC sub layer may have to send an end segment of an RLC SDU N 408, be able to send complete RLC SDUs N+1, N=2 410, 412, and then have to segment a final SDU 414 in the PDU to comply with the requested length.” （当RLC子层从MAC子层接收到所请求的RLC PDU长度时，RLC子层可能必须发送RLC SDU N 408的结束分段，能够发送完整的RLC SDU N+1、N+2 410、412，然后必须对PDU中的最后SDU 414进行分段以符合所请求的长度。） | 对比文件明确公开了在构建PDU时需要处理SDU分段。段落[0049]公开了RLC子层根据MAC层请求的大小动态构建PDU，支持SDU的分段，并且通过CP字段的两个比特来指示分段情况（第一SDU的开始和最后SDU的结束是否被分段）。段落[0051]和图7进一步公开了在组装PDU时，RLC子层需要确定哪些SDU可以被完整包含、哪些需要被分段，以及分段在SDU中的相对位置（如结束分段、完整SDU、开始分段等）。这些内容隐含了“确定SDU的分段是否要被包括在PDU中”以及“确定分段相对于SDU的位置”的过程。虽然对比文件没有使用与目标专利完全相同的表述步骤，但本领域技术人员可以从对比文件描述的PDU构建过程中合理推断出：在组装PDU时，发送实体会根据可用空间判断是否需要分段，并确定分段是SDU的第一分段、中间分段还是最后分段。因此，技术特征A被隐含公开。 |
| **技术特征B**：根据所述首先确定来确定是否将信息包括在所述报头部分中，并且如果将所述信息包括在所述报头部分中，则根据所述其次确定来确定所述报头部分中的所述信息的内容 ——《隐含公开》 | [0049] “For one SDU, these extra fields can be omitted, but for every additional SDU one Length Indicator (LI) 350 and one E bit 352 are added.” （对于一个SDU，这些额外字段可以省略，但对于每个附加的SDU，添加一个长度指示符(LI)350和一个E比特352。）[0049] “If there are more header fields, an LI 350 follows to indicate where the first SDU ends and where the next SDU starts. After the LI field 350 another E bit 352 follows. There will be one LI field 350 and one E bit 352 for every SDU 356 in each RLC PDU except for a last SDU 358.” （如果有更多报头字段，则跟随一个LI 350来指示第一SDU结束和下一SDU开始的位置。在LI字段350之后跟随另一个E比特352。对于每个RLC PDU中的每个SDU 356，除了最后SDU 358之外，将有一个LI字段350和一个E比特352。） | 对比文件公开了报头中LI字段的包含与否取决于PDU中SDU的数量和位置。段落[0049]指出对于单个SDU可以省略额外字段，对于多个SDU则需要添加LI和E字段，且最后SDU不需要LI字段。这体现了根据PDU中SDU的组成情况（即分段确定的结果）来决定是否在报头中包含LI信息。同时，LI字段的内容指示SDU结束/下一SDU开始的位置，这与分段位置相关。本领域技术人员可以从这些内容合理推断出：是否在报头中包含信息（如LI字段）是根据对SDU分段情况的确定结果来决定的，而信息的内容则与分段在SDU中的位置相关。因此，技术特征B被隐含公开。 |
| **技术特征C**：向接收器实体提供所述协议数据单元 ——《直接公开》 | [0047] “The MAC 304 requests PDUs 312 from the RLC sub layer 302 when it is scheduled to transmit...builds a PDU 314 out of it...Then the TB is transmitted as depicted 320.” （当MAC 304被调度传输时，它从RLC子层302请求PDU 312...构建PDU 314...然后传输块被传输，如320所示。）[0038] “the UE 106 builds packet data units (PDUs) from Radio Link Control (RLC) sub layer service data units (SDUs)” （UE 106从RLC子层SDU构建PDU。） | 对比文件明确描述了发送实体（UE）构建PDU后将其提供给接收实体的过程。段落[0047]结合图3描述了RLC子层根据MAC请求构建PDU，然后通过传输块（TB）进行传输。段落[0038]也指出UE构建PDU并通过空中链路与eNB通信。这些内容直接公开了将构建好的PDU提供给接收器实体的步骤。因此，技术特征C被直接公开。 |
| **技术特征D**：确定所述服务数据单元的所述分段的所述位置在所述服务数据单元的第一分段和最后分段之间，并且因此确定所述报头部分中的所述信息的所述内容指示分段偏移。 ——《未公开》 | 对比文件中未找到明确公开此技术特征的内容。 | 目标专利的技术特征D涉及一种特定场景：SDU分段既不是第一分段也不是最后分段（即中间分段），此时报头中的信息内容指示“分段偏移”（SO）。对比文件主要讨论了通过CP字段的两个比特来指示第一SDU开始和最后SDU结束是否被分段（[0049]），以及LI字段用于指示SDU边界。对比文件的PDU结构中，一个PDU内的SDU分段只能位于PDU的开始或结尾（即第一分段或最后分段），并未公开或暗示PDU包含中间分段（即既不是第一也不是最后分段）并为其提供分段偏移信息的情况。对比文件图7虽然显示了多个SDU的组装，但分段仅发生在最后一个SDU上。因此，对比文件未公开技术特征D。 |
| **技术特征E**：包括确定所述服务数据单元的所述分段是所述服务数据单元的第一分段，并且所述信息的内容指示所述服务数据单元长度。 ——《未公开》 | 对比文件中未找到明确公开此技术特征的内容。 | 目标专利的技术特征E明确要求：当分段是第一分段时，报头中的信息（LI字段）内容指示的是“整个SDU的长度”。对比文件[0049]中描述的LI字段用于“指示第一SDU结束和下一SDU开始的位置”，即指示SDU的边界，而非整个原始SDU的长度。在对比文件的方案中，当第一SDU被分段时，CP字段的第一比特指示开始是否被分段，但LI字段仍然指示该分段在PDU中的结束位置（即分段本身的长度），而不是整个原始SDU的总长度。目标专利中对第一分段LI字段的重新解释（指示整个SDU长度而非分段长度）是对比文件未教导的特定设计选择。因此，技术特征E未被公开。 |
| **技术特征F**：包括确定所述服务数据单元的所述分段是所述服务数据单元的最后分段，并且所述信息的内容指示所述服务数据单元分段长度。 ——《未公开》 | 对比文件中未找到明确公开此技术特征的内容。 | 目标专利的技术特征F要求：当分段是最后分段时，信息内容指示“SDU分段长度”。对比文件[0049]指出“对于每个RLC PDU中的每个SDU，除了最后SDU之外，将有一个LI字段和一个E比特”，并且“最后SDU的长度可以通过从RLC PDU长度中减去所有存在的LI之和来计算”。这意味着在对比文件中，最后SDU（无论是完整SDU还是分段）通常不需要LI字段，其长度通过计算得出。目标专利中针对最后分段使用LI字段指示分段长度的做法与对比文件的方案不同。对比文件未公开在最后分段场景下通过报头信息明确指示分段长度。因此，技术特征F未被公开。 |
| **技术特征G**：包括确定所述服务数据单元的所述分段是所述服务数据单元的最后分段并且填充所述协议数据单元，以及确定不将所述信息包括在所述报头部分中。 ——《直接公开》 | [0049] “There will be one LI field 350 and one E bit 352 for every SDU 356 in each RLC PDU except for a last SDU 358. The length of the last SDU 358 can be calculated by subtracting the length of the RLC PDU 340 with the sum of all present LIs. Padding 360 is added to the RLC header 342 to byte align RLC payload 362 if needed.” （对于每个RLC PDU中的每个SDU 356，除了最后SDU 358之外，将有一个LI字段350和一个E比特352。最后SDU 358的长度可以通过从RLC PDU 340的长度中减去所有存在的LI之和来计算。如果需要，填充360被添加到RLC报头342以字节对齐RLC有效载荷362。）[0051] “Unless the last SDU fits perfectly the last SDU will be segmented or padding added as appropriate to fill the requested size.” （除非最后SDU完全适合，否则最后SDU将被分段或适当添加填充以填满所请求的大小。） | 对比文件明确公开了：当PDU中的最后一个数据单元是最后SDU（或最后分段）且需要进行填充时，不为该最后SDU在报头中包含LI字段。段落[0049]明确说明每个SDU都有LI字段，“除了最后SDU”，其长度通过计算得出。段落[0051]和图7描述了当需要填充PDU时，对最后SDU进行分段或添加填充。结合这两处内容，本领域技术人员可以毫无疑义地确定：当最后分段填充PDU时，发送实体不为该分段在报头中包含LI信息。因此，技术特征G被直接公开。 |
| **技术特征H**：其中所述信息包括长度指示符字段。 ——《直接公开》 | [0049] “one Length Indicator (LI) 350 and one E bit 352 are added...If there are more header fields, an LI 350 follows to indicate where the first SDU ends and where the next SDU starts.” （添加一个长度指示符(LI)350和一个E比特352...如果有更多报头字段，则跟随一个LI 350来指示第一SDU结束和下一SDU开始的位置。）图5：RLC PDU结构图中明确标注了“LI 350”字段。 | 对比文件图5和段落[0049]明确公开了RLC PDU报头中包含长度指示符（LI）字段，并且描述了其功能是用于指示SDU的边界位置。这与目标专利中“信息包括长度指示符字段”的特征完全一致。因此，技术特征H被直接公开。 |
| **技术特征I**：其中所述报头部分包括成帧信息，所述成帧信息包括指示所述数据字段的第一字节是否对应于服务数据单元的第一字节的第一比特、以及指示所述数据字段的最后字节是否对应于服务数据单元的最后字节的第二比特。 ——《直接公开》 | [0049] “The Complete/Partial field 346 supports segmentation and concatenation by having a first bit that indicates if the start of the first SDU 354 is segmented while the second bit indicates if the end of the last SDU 356 is segmented.” （完整/部分字段346通过具有第一比特和第二比特来支持分段和级联，第一比特指示第一SDU 354的开始是否被分段，第二比特指示最后SDU 356的结束是否被分段。）图5：RLC PDU结构图中明确标注了“CP 346”字段，包含两个比特。 | 对比文件[0049]明确公开了CP（完整/部分）字段作为成帧信息，该字段包含两个比特：第一比特指示第一SDU的开始是否被分段（即数据字段的第一字节是否对应于SDU的第一字节），第二比特指示最后SDU的结束是否被分段（即数据字段的最后字节是否对应于SDU的最后字节）。这与目标专利中成帧信息的定义完全对应，第一比特和第二比特的功能相同。因此，技术特征I被直接公开。 |
| **技术特征J**：其中所述报头部分包括数据字段元素信息，所述数据字段元素指示所述数据字段中的数据字段元素的数目，并且包括在所述成帧信息的第二比特之后、并且在所述成帧信息的第一比特之前提供数据字段元素信息。 ——《未公开》 | 对比文件中未找到明确公开此技术特征的内容。 | 目标专利的技术特征J要求报头中包含一个“数据字段元素（DFE）信息”字段，用于明确指示数据字段中数据字段元素（即SDU/SDU分段）的数目，并且该字段在报头中的位置特定地安排在成帧信息的第二比特（LB）之后、第一比特（FB）之前。对比文件的RLC PDU结构（图5、[0049]）中，报头包含CP字段（相当于成帧信息）、SN字段、E字段和LI字段，但并未包含一个单独用于指示SDU数目的DFE字段。对比文件通过E比特的链式结构来指示是否存在更多报头字段，接收器需要顺序处理才能确定SDU的数量，而不是通过一个明确的DFE字段立即获知。对比文件也未公开DFE字段在CP字段的第二比特之后、第一比特之前的特定位置安排。因此，技术特征J未被公开。 |
| **技术特征K**：其中所述接收器实体是无线电链路控制实体。 ——《直接公开》 | [0038] “a transmitting Radio Link Control (RLC) entity (e.g., user equipment (UE))...a receiving RLC entity (e.g., eNB)” （传输RLC实体（例如UE）...接收RLC实体（例如eNB））[0052] “On the receiving side (e.g., eNB), when the RLC sub layer receives a RLC PDU from the MAC sub layer...” （在接收侧（例如eNB），当RLC子层从MAC子层接收到RLC PDU时...） | 对比文件多处明确指出接收器实体是RLC实体。段落[0038]直接提到了“接收RLC实体（例如eNB）”。段落[0052]描述了接收侧的RLC子层处理接收到的RLC PDU。因此，接收器实体为无线电链路控制实体这一特征被直接公开。因此，技术特征K被直接公开。 |
| **技术特征L**：其中所述报头部分包括序列号，并且所述序列号对应于被包括在所述协议数据单元中的第一服务数据单元的序列号。 ——《未公开》 | [0049] “An RLC header 342 consists of a Sequence Number 344...The Sequence Number 344 can be used for duplicate detection and in sequence delivery to the upper layer.” （RLC报头342由序列号344组成...序列号344可用于重复检测和向上层的按序递送。） | 对比文件[0049]公开了RLC PDU报头中包含序列号（SN）字段，但该序列号是PDU级别的序列号，用于重复检测和按序递送。目标专利明确要求序列号对应于“被包括在PDU中的第一SDU的序列号”，这是基于SDU的序列编号方案（SDU-based SN），与对比文件中基于PDU的序列编号方案（PDU-based SN）有本质区别。在目标专利的方案中（参见[0121]-[0123]、图5），SN分配给SDU而非PDU，因此连续的PDU如果包含相同SDU的分段则可能具有相同的SN。对比文件未公开或暗示这种基于SDU的序列编号方案。因此，技术特征L未被公开。 |
<<<c>>><<<g>>><<<h>>><<<i>>><<<k>>><<<a>>><<<b>>>