Data processing method and device, medium and product

Abstract

The invention discloses a data processing method and device, a medium and a product. The data processing method is applied to a first communication device, and comprises: sending a target data frame to a second communication device, the target data frame comprising a plurality of sub-payload regions and first verification information corresponding to each sub-payload region in the plurality of sub-payload regions. According to the invention, the reliability of data transmission can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method, apparatus, medium and product. Background Technology

[0002] With the surge in user network traffic and the iteration of communication technologies, the transmission bandwidth of mainstream services such as Ethernet has advanced from the early 10 Mbps and 100 Mbps speeds to 400 Gbps, 800 Gbps, and even 1.6 Tbps. In such high-speed transmission scenarios, customer data typically needs to be carried through next-generation service layer networks such as FlexO LO path.

[0003] However, the format characteristics of this type of service layer frame structure differ significantly from those of traditional networks. Currently, in the standardized data frame structures of next-generation service layers such as FlexO and LoPath, there is a lack of a clear and unified mechanism for carrying verification information for client data streams. This makes it difficult for the data receiver to effectively identify whether errors have occurred in the data frame during service layer transmission, thus affecting the overall reliability of data transmission. Summary of the Invention

[0004] This application provides a data processing method, device, medium, and product, which can at least improve the reliability of data transmission.

[0005] In a first aspect, embodiments of this application provide a data processing method applied to a first communication device, comprising:

[0006] Send a target data frame to the second communication device, wherein the target data frame includes multiple sub-payload areas and first verification information corresponding to each sub-payload area.

[0007] Secondly, embodiments of this application provide a data processing method applied to a second communication device, comprising: Receive a target data frame sent by a first communication device, wherein the target data frame includes multiple sub-payload areas and first verification information corresponding to each sub-payload area; Each sub-load area is processed based on the first verification information corresponding to each sub-load area.

[0008] Thirdly, embodiments of this application provide an electronic device, including: at least one processor; at least one memory for storing at least one program; and when at least one of the programs is executed by at least one of the processors, implementing the data processing method as described in the first aspect, or the data processing method as described in the second aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for performing the data processing method as described in the first aspect, or the data processing method as described in the second aspect.

[0010] Fifthly, embodiments of this application provide a machine program product, including a computer program or computer instructions, the computer program or computer instructions being stored in a computer-readable storage medium, a processor of a communication device reading the computer program or computer instructions from the computer-readable storage medium, and the processor executing the computer program or computer instructions to cause the communication device to perform the data processing method as described in the first aspect, or the data processing method as described in the second aspect.

[0011] In this embodiment, multiple sub-payload areas are set in the target data frame, and corresponding first verification information is configured for each sub-payload area. The division of the data frame into multiple independent transmission and verification units by these sub-payload areas directly associates the first verification information of each sub-payload area with the data carried within that sub-payload area. This achieves precise binding between verification information and data, ensuring comprehensive and targeted verification coverage. Regardless of the format differences between the Flex0 100 path frame structure and traditional networks, the verification mechanism can be adapted to the frame structure through the combination of sub-payload areas and corresponding first verification information. This makes the service layer's verification of client data streams universal and effective, thereby solving the problem of insufficient transmission reliability caused by the lack of a verification information carrying mechanism in the service layer and improving the reliability of data transmission. Attached Figure Description

[0012] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0013] Figure 1 This is a schematic diagram of the data structure of Ethernet packets in related technologies; Figure 2 This is a schematic diagram illustrating the mapping of a 257-bit code block to OTN. Figure 3 This is a schematic diagram illustrating the verification principle of data frames; Figure 4 This is a schematic diagram illustrating an application scenario of the data processing method provided in the embodiments of this application; Figure 5 This is a schematic flowchart of the data processing method provided in the first aspect of this application; Figure 6 This is a schematic diagram illustrating an application example of the data processing method provided in the embodiments of this application; Figure 7This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 8 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 9 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 10 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 11 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 12 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 13 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 14 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 15 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 16 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 17 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 18 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 19 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 20 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 21 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 22 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 23 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 24 This is a schematic diagram illustrating another application example of the data processing method provided in the embodiments of this application; Figure 25 This is a schematic flowchart of the data processing method provided in the second aspect of this application; Figure 26 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0015] It should be understood that in the description of the embodiments of this application, the use of terms such as "first" and "second" is only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of technical features indicated, or implicitly indicating the order of the technical features indicated. "At least one" refers to one or more, and "more" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any group of these items, including any group of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0016] The rapid increase in user network traffic has spurred a rapid increase in the bandwidth of communication network information transmission. The interface bandwidth speed of communication equipment has increased from 10M (unit: bits / second, the same below) to 100M, 1G, and 10G. Currently, 100G and 400G bandwidth speeds are in use, and 800G and 1.6T transmission methods are being developed.

[0017] Currently, the main customer business involves Ethernet packets. Ethernet packets require encoding before transmission, converting the packet content into a code block stream for transmission, such as... Figure 1Ethernet packets with speeds of 10G and 100G use a 64 / 66 encoding format. For Ethernet interfaces with speeds of 10G and above, the Ethernet protocol defines that Ethernet data packets are 64 / 66 encoded before transmission, expanding the 64-bit client byte content into a 66-bit information block. The added 2 bits are placed at the beginning of the 66-bit block as a start marker. The 64 / 66 encoding rule defined by the 802.3 protocol is that each code block consists of 66 bits. The first 2 bits are the synchronization header of the code block. If the synchronization header bit is "01", it indicates that it is a D code block (data code block). The following 8 bytes (64 bits) are the 8 bytes of data content of the Ethernet packet. If the synchronization header bit is "10", it indicates that it is a control code block (the control code block is a general term for all control-type code blocks). The first byte following is the block type field (also called the control type value, type value, control value, etc.), which indicates the specific type of control block. The next 7 bytes are the content of the control block, and the 7 bytes of content are related to the specific type of control block.

[0018] As Ethernet service speeds increase, 64 / 66 encoding is performed on high-speed PHY interfaces, and then the 66-bit blocks are encoded using 256 / 257 encoding (or transcoding). 256 / 257 encoding is more efficient than 64 / 66 encoding (64 / 66 encoding efficiency is 96.97%, 256 / 257 encoding efficiency is 99.61%), and the final result for high-speed services uses 256 / 257 block encoding. The encoding principle of 256 / 257 blocks is to encode four 66-bit blocks into 257-bit blocks. This conversion saves 7 synchronization header bits, resulting in higher encoding efficiency. 257 blocks are used in interfaces with speeds of 100G and above. For specific transcoding rules from 66 to 257 blocks, refer to the Ethernet 802.3 standard.

[0019] The Ethernet standard defines a message length of 64-9600 bytes. The last four bytes of the message are 32-byte Cyclic Redundancy Check (CRC) bytes, which verify the preceding content to check for bit errors during transmission. However, the CRC algorithm has a small probability of missing detections. This means that under certain bit errors, the CRC result might happen to be the same as no error, leading to the receiver failing to detect the error and accepting it as correct – a missed detection. At the specified bit error rate, the time interval between missed detections and acceptance of erroneous messages as correct messages is greater than 4.6 billion years, meeting the Mean Time To False Packet Acceptance (MTTFPA) requirement defined by Ethernet. After the message is encoded, the synchronization header bits in the 66 (or 257) bit code block are crucial, determining the type of code block.

[0020] If the synchronization bit of a code block is faulty, the code block will change from a data code block to a control code block, or vice versa. The characteristics of the code block will change completely, leading to serious consequences. The error rate will increase significantly, causing the probability of missed CRC32 checks in Ethernet to increase sharply, making it impossible to meet the performance requirements.

[0021] To verify whether client code blocks are corrupted during transmission through the service layer and meet the missed detection criterion, a separate, service-layer CRC checksum calculation (unrelated to Ethernet's own CRC32 checksum algorithm) is performed on the client code blocks at the service layer to detect errors during transmission. When a transmission error is detected, it is marked at the end of the message, and the receiving end discards the erroneous message based on the marking. By marking and discarding errors during transmission, the service layer reduces the error probability at the service layer and the overall missed detection probability, thus meeting the missed detection criterion.

[0022] When Ethernet packets such as 100 Gigabit Ethernet (100GE) are transmitted through an optical transport network (OTN) (taking the OTN network as an example as the service layer), the 257-bit code block encoded by the customer service is mapped into the frame structure of the OTN for transmission.

[0023] like Figure 2As shown. At the receiving end, a 257-bit code block is extracted from the OTN frame to recover the original Ethernet message. The Ethernet standard defines a message length of 64-9600 bytes, with the last 4 bytes being CRC32 checksum bytes to verify the preceding content and check for errors during transmission.

[0024] For example, at the sending end, when the client transmits frames through the service layer, an independent CRC checksum is added to the service layer. The content of all 257 code blocks of a certain length in the client's memory is calculated using CRC32 at the service layer (this example uses CRC32; other algorithms such as CRC16, CRC24, etc., can be used in the actual implementation). The CRC32 calculation result is placed in a separate CRC32 storage location at the service layer. Figure 3 This involves performing a CRC32 check on all bits in a 257-bit code stream, from the first 257-bit block to the last 257-bit block. The CRC32 check polynomial conforms to the IEEE 802.3-2022 definition and is expressed as: G(x) = x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1.

[0025] At the receiving end, the same CRC32 check algorithm is performed. The CRC32 check result at the receiving end is compared with the carried CRC32 value. If they are the same, it means that the result transmitted through the service layer frame is correct. Otherwise, if the CRC32 content calculated by the receiving end is different from the carried CRC32 content, it means that there is an error in the result transmitted through the service layer frame, and all 257 code blocks in this segment need to be replaced with error code blocks. Figure 3 As shown, when the CRC32 check result generated by the receiving end is not equal to the CRC32 value carried, all 257s in the corresponding CRC32 check area are replaced with error code blocks. In this way, there is at least one error code block in the message. If an error flag code block is detected in the message during reception, the message is discarded, thus meeting the requirements of the missed detection index.

[0026] When Ethernet packets such as 100GE pass through the FlexO lo path layer as the service layer, it is also necessary to address the issue of MTTFPA non-compliance caused by encoding, transcoding, and other reasons. The lo path frame structure is as follows: Figure 4 As shown, the lopath frame structure begins with overhead bytes, which are the first bytes of the overhead frame structure. Figure 4 The OH portion (in the text) is between 4x16 (i.e., 64) and 10x16 (i.e., 160) bytes long, followed by the container portion (i.e., ... Figure 4 The payload area (in the container) has a length of 5130x16 (i.e., 82080) bytes, and carries 257-bit code blocks within it. Since the container length of 656640 bits (82080 bytes) is not a multiple of 257 bits, the container can hold 2555 257-bit code blocks, leaving 5 bits of free space. In practical applications, 5 free bits can be placed at the beginning of the container, followed by 2555 257-bit code blocks, such as... Figure 4 .

[0027] The client's 257-bit code block stream speed is slightly lower than the lo path frame container speed. Therefore, the container is generally not fully filled with 257-bit code blocks; some 257-bit block positions are fixed-position code blocks. In practical applications, when carrying 257-bit code blocks, the carrying method is calculated every four frames (four consecutive frames constitute a multiframe). Based on the deviation between the client's speed and the container's speed, the number of fixed-position 257-bit code blocks inserted into the container is determined. Figure 4 The calculation determines that two fixed 257-bit code blocks need to be inserted in four frames. The Sigma algorithm is then applied to calculate the positions of these two fixed 257-bit code blocks, ensuring that their positions are evenly distributed. Figure 4 The document provides the positions of two fixed 257-bit code blocks calculated by the Sigma algorithm: the first 257-bit code block position in the second frame and the first 257-bit code block position in the fourth frame. These two positions are for fixed 257-bit code blocks, while the remaining positions carry the client's 257-bit code blocks. It should be noted that this is only an illustrative example. The number of fixed 257-bit code blocks inserted in each multiframe can be flexibly adjusted according to the deviation between the actual client service speed and the speed of the lo path frame container. Furthermore, the fixed code block positions calculated by the Sigma algorithm can be dynamically adapted according to the principle of uniform distribution and are not limited to this. Figure 4 The specific location is shown. Furthermore, the arrangement of the 5-bit free space in the container can be flexibly adjusted, for example, by distributing it across different locations within the container, or by using it in conjunction with a fixed-insertion code block, as long as the full carrying requirements of the 257-bit code block and the transmission rate adaptation requirements are met. All variations in the above-mentioned specific implementation methods do not depart from the core technical concept of this application.

[0028] When sending a 257-bit code block carrying customer services in the FlexO 100 path, an independent CRC checksum needs to be added to the FlexO 100 path service layer. The service layer performs CRC calculations on the contents of all 257-bit code blocks of a certain length in the customer's data, stores the CRC result, and sends it to the receiving end. The receiving end repeatedly calculates the CRC value of the customer's 257-bit code block and compares it with the CRC value carried by the service layer. If they are different, it indicates an error in the service layer's transmission process, and the potentially erroneous 257-bit code block needs to be replaced with the erroneous code block. However, how the FlexO 100 path frame carries and transmits the CRC value calculated by the sending end is currently unsolved.

[0029] Based on this, embodiments of this application provide a data processing method, device, medium, and product. By setting multiple sub-payload areas in the target data frame and configuring corresponding first verification information for each sub-payload area, the division of the data frame into multiple independent transmission and verification units is achieved. The first verification information corresponding to each sub-payload area is directly associated with the data carried within that sub-payload area, realizing precise binding between verification information and data. This ensures the comprehensiveness and specificity of verification coverage. Regardless of the format characteristics differences between the Flex0 100 path frame structure and traditional networks, the verification mechanism can be adapted to the frame structure through the combination of sub-payload areas and corresponding first verification information. This makes the verification of client data streams by the service layer universal and effective, thereby solving the problem of insufficient transmission reliability caused by the lack of a verification information carrying mechanism at the service layer and improving the reliability of data transmission.

[0030] The data processing method provided by the first aspect of this application will be described in detail below with reference to the accompanying drawings and through some embodiments and application scenarios.

[0031] See Figure 5 , Figure 5 This is a schematic flowchart of the data processing method provided in the first aspect of this application.

[0032] like Figure 5 As shown, the data processing method is applied to a first communication device, and the method includes, but is not limited to, the following steps: S501, a target data frame is sent to the second communication device, wherein the target data frame includes multiple sub-payload areas and first verification information corresponding to each of the multiple sub-payload areas.

[0033] The S501 will be described in detail below.

[0034] In S501, the target data frame is the carrier for data transmission from the first communication device to the second communication device. Specifically, it can be a FlexO 1Lo path frame, whose structure conforms to the relevant FlexO technical specifications and consists of an overhead field and a payload area. The overhead field is 64-160 bytes long and is used to carry basic transmission information such as frame synchronization and rate negotiation. The payload area is 82080 bytes long and is divided into multiple sub-payload areas to carry 257-bit code block streams. It should be noted that this application is not limited to the aforementioned FlexO 1Lo path frame; it can also be other service layer data frames with overhead fields and payload area division capabilities, such as OTN frames and Ethernet frames. As long as the data frame can support subdividing the payload area into multiple sub-payload areas and configuring corresponding first check information for each sub-payload area, it falls within the protection scope of this application.

[0035] Sub-payload areas are subdivided units of the target data frame payload area. They can be divided according to transmission requirements and verification accuracy requirements. There are two division methods: equal division and unequal division. In equal division, the payload area is divided into 4, 8, or 16 equal parts (e.g., in 16 equal parts, each sub-payload area has a capacity of 5130 bytes). In unequal division, the first sub-payload area can contain 5 free bits and an integer number of 257-bit code blocks, while the remaining sub-payload areas only contain an integer number of 257-bit code blocks, ensuring that each 257-bit code block completely belongs to one sub-payload area.

[0036] The first communication device is the main implementer of this data processing method. It is a communication network device with data transmission capabilities, specifically a sending end device at the FlexO10 path layer (such as a router, switch, or transmission gateway). Its core function is to process customer service data and send the target data frame to the second communication device.

[0037] The second communication device is the main receiver of the target data frame. It is a communication network device that communicates and interconnects with the first communication device, and can be specifically a receiving end device in the FlexO 100 path layer (such as a router, switch, terminal access device, etc.). Its core function is to receive the target data frame sent by the first communication device, extract each sub-payload area and the corresponding first check information, and realize error detection and location of the 257-bit code block stream.

[0038] The first verification information is a verification credential generated by the first communication device for each sub-payload area. It is used by the second communication device to verify the integrity of the sub-payload area data. Specifically, it can be divided into two categories: CRC checksum and authentication value. The CRC checksum is generated by performing a CRC algorithm (such as CRC32, CRC16, etc.) on the 257-bit code block stream in the sub-payload area. The authentication value is generated in the sub-payload area data encryption scenario and is calculated by the sending end based on the encrypted data, encryption parameters, etc. The purpose of the first verification information is to enable the receiving end to identify whether errors have occurred during data transmission.

[0039] Optionally, in this embodiment of the application, the method for dividing the payload area of ​​the target data frame is determined. The division rules can be flexibly set according to actual transmission requirements, and may include at least the following methods: 1. The first communication device pre-configures the partitioning rules, that is, the first communication device pre-sets the number and partitioning mode (equal partitioning or unequal partitioning) of sub-payload areas according to the FlexO 100 path layer transmission protocol specification and the preset verification accuracy requirements, and the boundaries and capacity of each sub-payload area are clearly defined before data transmission. 2. The first communication device dynamically formulates the division rules in real time. That is, after receiving customer service data, it dynamically determines the division scheme of sub-payload areas based on the current customer data volume and transmission rate deviation, so as to ensure that each sub-payload area can adapt to the data carrying and verification requirements after division. 3. The target data frame itself has a pre-defined structure according to customer requirements. That is, the number and capacity of the sub-payload areas are determined in the design phase based on the customer's business scenario and transmission quality requirements. The first communication device can directly use this pre-defined structure without additional division.

[0040] The method for generating the first verification information can be flexibly selected according to the business scenario, and at least includes the following methods: 1. In unencrypted scenarios, the CRC algorithm can be used to perform a check operation on the 257-bit code block stream in each sub-payload area to obtain the initial check information. This initial check information can be directly used as the first check information. If the number of bits in the initial check information exceeds the number of bits that the data frame can carry, the initial check information is compressed to obtain the first check information. 2. In encrypted scenarios, encryption algorithms can be used to encrypt the data in the sub-payload area. Then, an authentication value can be generated based on parameters such as the encrypted data, encryption key, and initial vector. If the number of bits in the authentication value exceeds the carrying capacity of the data frame, it can be adapted through a compression algorithm. 3. Other verification mechanisms, such as hash verification algorithms and parity verification algorithms, can also be used to generate the first verification information, as long as they can achieve the data integrity verification of the sub-payload area.

[0041] Finally, after the first verification information is generated, the first communication device integrates the divided sub-payload areas with the corresponding first verification information to construct a target data frame that conforms to the FlexO lo path frame structure specification, and then sends the target data frame to the second communication device through the communication interface.

[0042] In one embodiment, the first verification information corresponding to each sub-load area is carried in the target area corresponding to each sub-load area; The target area corresponding to each sub-net load area is determined based on at least one of the following: The overhead field of the target data frame; The target fixed-insertion code block corresponds to the target data frame; the target fixed-insertion code block is a fixed-insertion code block configured for N data frames, where N is an integer greater than 1, and the N data frames include the target data frame.

[0043] Optionally, in this embodiment, the target area is a specific region in the target data frame used to carry the first verification information of the corresponding sub-payload area. The determination of the target area can be varied; it can be determined solely based on the overhead field of the target data frame, solely based on the target fixed-insertion code block, or a combination of both, thus adapting to the verification information carrying requirements in different scenarios.

[0044] Fixed-insertion blocks are blocks configured to accommodate the rate difference between the customer business block stream and the container of the target data frame. They only serve to fill free space and do not carry any customer business data.

[0045] Since the customer's 257-bit code block stream speed is slightly lower than the carrying speed of the target data frame container, there will be some idle positions in the container that are not occupied by service data. Fixed-insertion code blocks are used to fill these idle positions to ensure the standardization of the data frame structure and the stability of transmission. Meanwhile, the configuration of fixed-insertion code blocks is based on multiframes consisting of N data frames. N data frames refer to multiple consecutive data frames that are calculated as a whole for the carrying method. The number of these frames can be set according to the transmission protocol specifications and rate adaptation requirements; for example, it can be that every four frames form a multiframe. By uniformly calculating the number and position of fixed-insertion code blocks within the multiframe, the uniformity of code block distribution is ensured.

[0046] A target fixed-insertion block is a fixed-insertion block in a multiframe composed of N data frames, specifically used to carry the first checksum information of the current target data frame. Within the multiframe, the total number of fixed-insertion blocks to be inserted is first determined based on the deviation between the customer's service speed and the container speed. Then, the specific distribution positions of these blocks within the multiframe are calculated using the sigma algorithm to achieve uniform distribution. It should be noted that some data frames may be assigned one or more fixed-insertion blocks, while others may not be assigned any; the allocation depends entirely on the rate deviation adaptation requirements.

[0047] Optionally, in the embodiments of this application, the method for determining the target area includes at least the following methods: 1. Based on the determination of the overhead field of the target data frame, redundant overhead fields (the part exceeding the basic functions of frame synchronization, rate negotiation, etc.) can be divided in the overhead field of the target data frame. According to the number of sub-payload areas and the number of bits of the first check information, the redundant overhead fields are allocated to each sub-payload area equally or as needed to form the target area corresponding to each sub-payload area. For example, the 16-byte overhead field is evenly distributed to 16 sub-payload areas, and each sub-payload area corresponds to a 1-byte (8-bit) target area to carry the first check information. 2. Based on the determination of the target fixed-insertion code blocks, first treat N data frames as a whole. Based on the rate deviation between the customer service code block stream and the frame container, determine the total number of fixed-insertion code blocks (2-7) to be inserted into the multiframe. Then, split all fixed-insertion code blocks in the multiframe according to a uniform rule (each split into a 256-bit data segment and a 1-bit marker). All 256-bit data segments are then aggregated and evenly distributed according to the number of sub-payload areas. For example, if there are x (x=2-7) fixed-insertion code blocks in the multiframe, the total 256x-bit data segments are split according to the total number of sub-payload areas in the multiframe, and the corresponding shares are then evenly distributed to the end of each sub-payload area of ​​the target data frame, forming the target area corresponding to each sub-payload area.

[0048] For a concrete example: Assume N=4 (4 frames make up a multiframe), and the payload area of ​​each target data frame is divided into 8 sub-payload areas, for a total of 32 sub-payload areas within the multiframe. Based on the rate deviation, 4 fixed-insertion code blocks (x=4) need to be inserted. Each of these 4 fixed-insertion code blocks is split into 256-bit data segments, resulting in a total of 4×256=1024 bits of data segments. After being evenly distributed among the 32 sub-payload areas, each sub-payload area is allocated a 32-bit (1024÷32) share. For the target data frame (such as the first frame of the multiframe), each of its 8 sub-payload areas receives a 32-bit share. These shares are then embedded at the end of the corresponding sub-payload area, forming a dedicated 32-bit target area for each sub-payload area. 3. The target region is determined by combining the overhead field of the target data frame with the target fixed-insertion code blocks. This approach leverages the advantages of the previous two methods, simultaneously utilizing the redundant portion of the overhead field and the available resources of all fixed-insertion code blocks within the multiframe. Specifically, the following steps are implemented: First, redundant overhead fields are partitioned within the overhead field of the target data frame. A basic bearer share is allocated based on the number of sub-payload areas (e.g., a 16-byte overhead field is evenly distributed among 16 sub-payload areas, with each sub-payload area receiving an 8-bit basic share). Then, following the fixed-insertion code block processing logic at the multiframe level, the 256x-bit data segments resulting from the splitting of x fixed-insertion code blocks within the multiframe are aggregated and evenly distributed according to the total number of sub-payload areas within the multiframe. An additional bearer share is allocated to each sub-payload area (e.g., 4 fixed-insertion code blocks correspond to 1024 bits, with each of the 32 sub-payload areas receiving a 32-bit additional share). Finally, the basic share and additional share of each sub-payload area are merged to form the target region with the total bearer share. For a specific example: N=4 (4 frames make up a multiframe), each frame is divided into 16 sub-payload areas, the multiframe has a total of 64 sub-payload areas, x=3 fixed stuffing blocks; first, allocate 1 byte (8 bits) of extra overhead field to each of the 16 sub-payload areas of each frame as the basic share, then divide the 3×256=768 bits of fixed stuffing block data segment equally into the 64 sub-payload areas, each sub-payload area gets an extra 12 bits share, and finally each sub-payload area of ​​the target data frame forms a 20-bit (8+12) target area.

[0049] In these alternative embodiments, the target area is determined by the overhead field, the target fixed-insertion code block, or a combination of both, flexibly adapting to the structural characteristics of the target data frame and efficiently carrying the first verification information. This approach avoids consuming excessive additional bandwidth resources while achieving accurate verification of the sub-payload area, ensuring data transmission reliability.

[0050] In one embodiment, the target area corresponding to each sub-net load area is determined in the following manner: Based on the overhead configuration of the overhead field of the target data frame, the target area corresponding to each sub-payload area is determined; the overhead configuration is used to indicate whether there are redundant overhead fields that exceed the basic functions of the overhead field.

[0051] Optionally, in this embodiment, the basic functions of the overhead field include necessary functions to ensure the normal transmission of data frames, such as carrying frame synchronization, rate negotiation, and frame identification, with a corresponding byte length of 64-160 bytes (conforming to the FlexO lopath frame structure specification). If the actual configured byte number of the overhead field exceeds the bytes required for the basic functions, the excess part is the redundant overhead field, and the overhead configuration will clearly mark the existence status, byte number, and distribution location of the redundant overhead field.

[0052] Optionally, in one specific implementation of this application, the first communication device first obtains the overhead configuration of the overhead field of the target data frame and determines whether there are any redundant overhead fields beyond the basic functions. If the overhead configuration indicates that there are no redundant overhead fields, then no additional processing is required for the overhead fields, and the target area is determined by using a target fixed-insertion code block. The specific determination method can be referred to the foregoing embodiments, and will not be repeated here.

[0053] If redundant overhead fields are indicated, they are allocated based on the number of sub-payload areas in the target data frame payload (e.g., 4, 8, or 16) and the bit requirement of the first checksum. Allocation can be done using an equal allocation method, splitting the redundant overhead fields evenly across the number of sub-payload areas, ensuring each sub-payload area receives a fixed number of bits for the target area; or using an on-demand allocation method, flexibly allocating redundant overhead field resources based on the number of 257-bit code blocks carried by each sub-payload area and the required checksum accuracy. For example, when the redundant overhead field is 16 bytes (128 bits) and the payload is divided into 16 sub-payload areas, an equal allocation method can ensure each sub-payload area corresponds to a 1-byte (8-bit) target area to carry the compressed CRC checksum value, ultimately determining the target area corresponding to each sub-payload area.

[0054] If on-demand allocation is adopted, assuming that in the 16 sub-payload areas, the first 4 sub-payload areas each carry 320 257-bit code blocks (with high verification accuracy requirements), and the last 12 sub-payload areas each carry 160 257-bit code blocks (with moderate verification accuracy requirements), then the excess overhead fields are allocated according to the "verification accuracy priority": 2 bytes (16 bits) of target area are allocated to each of the first 4 sub-payload areas, occupying a total of 4 × 16 = 64 bits; the remaining 128 - 64 = 64 bits are evenly distributed among the last 12 sub-payload areas, with each sub-payload area allocated 5 bits (12 × 5 = 60 bits). The remaining 4 bits can be flexibly allocated to any 4 of the last 12 sub-payload areas (making their target areas 6 bits). Finally, the first 4 sub-payload areas correspond to 16-bit target areas, and the last 12 sub-payload areas correspond to 5-bit or 6-bit target areas, thus completing the determination of the target areas corresponding to each sub-payload area.

[0055] In these alternative embodiments, the target area is determined based on the overhead configuration, and redundant overhead fields are flexibly used to carry verification information without occupying additional bandwidth resources, thereby improving error detection efficiency.

[0056] In one embodiment, the target area corresponding to each sub-payload area is determined based on the overhead configuration of the overhead field of the target data frame; the overhead configuration includes: When the overhead configuration indicates that the overhead field has the redundant overhead field, the target area is determined based on at least one of the following: the redundant overhead field, the target fixed stuffing code block corresponding to the target data frame; When the overhead configuration indicates that the overhead field does not contain the redundant overhead field, the target area is determined based on the target fixed insert code block corresponding to the target data frame.

[0057] Optionally, in one specific implementation of this application, the first communication device first obtains the overhead configuration information of the overhead field of the target data frame to determine whether there are redundant overhead fields exceeding basic functions such as frame synchronization and rate negotiation. If the overhead configuration indicates the existence of redundant overhead fields, the target area can be flexibly determined based on the redundant overhead fields alone, based on the target fixed-insertion code block alone, or by combining both. If the overhead configuration indicates no redundant overhead fields, the target area is directly determined based on the target fixed-insertion code block. The specific allocation logic, splitting rules, and bearer methods can be referred to the foregoing embodiments, and will not be repeated here.

[0058] In these alternative embodiments, the target area determination method is flexibly selected based on the overhead configuration. When there are redundant overhead fields, resources can be flexibly combined; when there are no redundant overhead fields, fixed inserted code blocks are reused, without requiring a large amount of additional bandwidth. This adapts to different frame structure scenarios and ensures data transmission reliability.

[0059] In one embodiment, the target area corresponding to each sub-net load area is determined in the following manner: Based on the overhead field and the number of first zones in the multiple sub-payload zones in the target data frame, the target zone corresponding to each sub-payload zone in the target data frame is determined.

[0060] Optionally, in one specific implementation of this application, the first communication device first identifies the redundant overhead fields in the target data frame overhead field that exceed the basic functions, counts their total number of bytes (or bits), and simultaneously determines the number of sub-payload areas (e.g., 4, 8, or 16) to which the target data frame payload area is divided. Then, the redundant overhead fields are equally allocated according to the number of sub-payload areas, ensuring that each sub-payload area receives a target area of ​​a fixed size. The allocation logic is "total number of bits in redundant overhead fields ÷ number of sub-payload areas = number of target area bits in a single sub-payload area". For example, if the redundant overhead fields are 16 bytes (128 bits) and the number of sub-payload areas is 16, then each sub-payload area is allocated a 1-byte (8-bit) target area.

[0061] In other implementations, redundant overhead fields can be allocated on demand. Resources can be flexibly allocated based on the number of 257-bit code blocks carried by each sub-payload area, the verification accuracy requirements, or the service priority. For example, in 16 sub-payload areas, 8 carry high-priority services (which need to carry the complete CRC32 value) and 8 carry ordinary-priority services (which only need to carry the compressed CRC8 value). If the redundant overhead field is 48 bytes (384 bits), then 4 bytes (32 bits) of target area are allocated to each of the high-priority sub-payload areas, occupying a total of 32 bytes. The remaining 16 bytes are evenly distributed among the 8 ordinary-priority sub-payload areas, with each area allocated 2 bytes (16 bits) of target area.

[0062] In these alternative embodiments, the target area is determined by combining the overhead field with the number of sub-payload areas in the first region, ensuring that the verification information is carried evenly and improving the efficiency of bit code block error detection.

[0063] In one embodiment, determining the target area corresponding to each sub-payload area in the target data frame based on the overhead field and the number of first areas of multiple sub-payload areas in the target data frame includes: Based on the number of the first area, the redundant overhead fields in the overhead fields are allocated to each of the sub-payload areas in the target data frame to obtain the target area corresponding to each sub-payload area in the target data frame; the redundant overhead fields are the extra fields in the overhead fields that exceed the basic functions of the overhead fields.

[0064] Optionally, in the embodiments of this application, such as Figures 6-11 As shown, at least the following examples are included: like Figure 6 As shown, the first region has 16 regions, with a redundant overhead field of 16 bytes. The 82080-byte payload area of ​​the FlexO lo path frame is divided into 16 equal sub-payload areas according to the number of regions in the first region. Each sub-payload area has a capacity of 5130 bytes. The 16-byte redundant overhead field is evenly distributed to each sub-payload area according to the number of regions in the first region. Each sub-payload area is allocated a corresponding 1-byte target area to carry the CRC calculation result. If the CRC32 algorithm is used, its calculation result is 32 bits (4 bytes). It needs to be compressed into 8 bits (1 byte) by compression methods such as direct truncation or polynomial remapping before being placed in the target area.

[0065] like Figure 7As shown, the first payload area has 16 regions, with a redundant overhead field of 32 bytes (twice the 16 bytes). The payload area is divided into 16 equal sub-payload areas, each with a capacity of 5130 bytes. The 32-byte redundant overhead field is equally distributed according to the number of regions in the first payload area. Each sub-payload area is allocated a corresponding 2-byte target area. When using the CRC32 algorithm, the 32-bit CRC result is compressed into 16 bits (2 bytes) before being carried in the target area.

[0066] like Figure 8 As shown, the first zone has 16 sections, with a redundant overhead field of 64 bytes (4 times the 16 bytes). The payload area is divided into 16 equal sub-payload areas based on the number of sections in the first zone. Each sub-payload area has a capacity of 5130 bytes, with 64 bytes of redundant overhead field allocated equally to each section. Each sub-payload area corresponds to a 4-byte target area. When using the CRC32 algorithm, the 32-bit CRC result does not need to be compressed and can be directly carried in the target area.

[0067] like Figure 9 As shown, the first payload area has 8 sections, with 16 bytes of redundant overhead field. The 82080-byte payload area is divided into 8 equal sub-payload areas, each with a capacity of 10260 bytes. The 16-byte redundant overhead field is equally distributed according to the number of sections in the first payload area. Each sub-payload area is allocated 2 bytes of target area. When using the CRC32 algorithm, the 32-bit CRC result needs to be compressed into 16 bits (2 bytes) before being placed in the target area.

[0068] like Figure 10 As shown, the first zone has 8 sections, with a redundant overhead field of 32 bytes (twice the 16 bytes). The payload area is divided into 8 equal sub-payload areas based on the number of sections in the first zone. Each sub-payload area has a capacity of 10260 bytes, with 32 bytes of redundant overhead field allocated equally to each section. Each sub-payload area is allocated a corresponding 4-byte target area. When using the CRC32 algorithm, the 32-bit CRC result can be directly carried in the target area without compression.

[0069] like Figure 11 As shown, there are four first-zone regions with a 16-byte redundant overhead field. The payload area is divided into four equal sub-payload regions, each with a capacity of 20,520 bytes. A 16-byte redundant overhead field is allocated equally among the first-zone regions. Each sub-payload region corresponds to a 4-byte target area. When using the CRC32 algorithm, the 32-bit CRC result can be directly carried in the target area without compression.

[0070] In these alternative embodiments, the excess portion of the multiplexing overhead field is allocated to the target area according to the number of first zones, without requiring additional bandwidth resources. The allocation logic aligns with the sub-payload area configuration, efficiently carrying verification information, improving the accuracy of data transmission error detection, and balancing resource utilization and transmission stability.

[0071] In one embodiment, among the multiple sub-payload areas in the target data frame, the size of the first sub-payload area is configured to accommodate the excess padding bits and P complete code blocks of the multiple sub-payload areas, and the remaining sub-payload areas are configured to accommodate Q complete code blocks; P and Q are both positive integers.

[0072] Optionally, in this embodiment, redundant padding bits refer to the difference between the total number of bits in the payload area (container) of the target data frame (such as a FlexOlopath frame) and the total number of bits actually carried in an integer number of complete 257-bit code blocks. Taking a FlexOlopath frame as an example, its payload area capacity is 82080 bytes (656640 bits). However, dividing 656640 bits by 257 bits does not yield an integer result, ultimately only able to carry 2555 complete 257-bit code blocks. The remaining 5 bits not occupied by complete code blocks are the redundant padding bits. These bits must be concentrated in the first sub-payload area to ensure that the remaining sub-payload areas only accommodate an integer number of complete 257-bit code blocks. It should be noted that in other implementations, the redundant padding bits can also be concentrated in any one of the multiple sub-payload areas, not limited to the first sub-payload area. The core is to ensure that the remaining sub-payload areas accommodate an integer number of complete 257-bit code blocks.

[0073] It should be noted that a complete code block refers to a standard-length code block adapted to the transmission rules of the target data frame (such as a FlexOlo path frame). Its specific length is determined by the encoding and carrying mechanism of the data frame, and is not limited to 257 bits. Taking the FlexOlo path frame as an example, its core is used to carry a 257-bit code block, so the complete code block here is a 257-bit code block. If the target data frame uses other encoding protocols (such as 64 / 66 encoding), the complete code block corresponds to a 66-bit code block, the core of which is a code block unit that conforms to the standard encoded length of the frame structure and can independently participate in verification and transmission.

[0074] Optionally, in the embodiments of this application, in Figures 6-11The proposed scheme divides the FlexO lo path frame payload area into many equal sub-payload areas, adding an overhead field to each sub-payload area to carry the CRC result. The advantage is that each sub-payload area is the same size, and the steps for performing CRC checks on each sub-payload area are identical, making CRC processing simple and convenient. However, it has another disadvantage: because the total number of bits in the sub-payload area is not an integer multiple of a 257-bit code block, the last 257 bits in a sub-payload area only contain the first half, with the second half located in the next sub-payload area. Figure 12 That is, there is a 257-bit code block that spans the CRC field and is located in the two sub-payload areas. If the CRC check result of either of the two sub-payload areas fails to be compared, the 257-bit code block needs to be modified into an error code block.

[0075] Therefore, in the specific implementation, the size of the sub-payload area can be designed to be different, ensuring that each sub-payload area stores an integer number of 257-bit code blocks. For example, the area can be divided into 16 sub-payload areas, with the first sub-payload area having a size of 5 + 155. 257 bits, storing 5 bits and 155 257-bit code blocks, with the 2nd to 16th sub-payload areas having a size of 160. 257 bits, storing 160 257-bit code blocks. Each 257-bit code block resides entirely within a unique sub-payload area. When the CRC check of a sub-payload area fails, the 257-bit code block can be easily modified into an error block. For example, when dividing into 8 sub-payload areas, the first sub-payload area has a size of 5 + 315. 257 bits, storing 5 bits and 315 257-bit code blocks, with the 2nd to 8th sub-payload areas having a size of 320. 257 bits, storing 320 blocks of 257 bits each, ensuring that each 257-bit block resides entirely within a single sub-payload region. When divided into 4 sub-payload regions, the first sub-payload region has a size of 5 + 635. 257 bits, storing 5 bits and 635 257-bit code blocks, with the second to fourth sub-payload areas having a size of 640. 257 bits, storing 640 257-bit code blocks, so that each 257-bit code block is entirely in a sub-payload area, which makes it easy to replace the previous 257-bit code block when the CRC result comparison fails.

[0076] like Figures 13-18 As shown, at least the following examples are included: like Figure 13As shown, the first region has 16 regions, with a 16-byte redundant overhead field. The 82080-byte payload area of ​​the FlexO lo path frame is divided into 16 sub-payload areas according to the number of regions in the first region (the first region contains 5 redundant padding bits + 155 complete 257-bit code blocks, and the remaining regions each contain 160 complete code blocks). The 16-byte redundant overhead field is evenly distributed according to the number of regions in the first region, and each sub-payload area is allocated 1 byte of target area. When using the CRC32 algorithm, the 32-bit result needs to be compressed into 8 bits before being carried.

[0077] like Figure 14 As shown, the first region has 16 regions, with a redundant overhead field of 32 bytes. The payload region is divided into 16 regions (the first region contains redundant padding bits + 155 code blocks, and the remaining regions each have 160 code blocks), with an equal allocation of 32 bytes of redundant overhead field. Each sub-payload region is allocated 2 bytes of target area. When using the CRC32 algorithm, the 32-bit result needs to be compressed into 16 bits before being carried.

[0078] like Figure 15 As shown, the first region has 16 regions, with a redundant overhead field of 64 bytes. The payload region is divided into 16 regions (the first region contains redundant padding bits + 155 code blocks, and the remaining regions each have 160 code blocks), with 64 bytes of redundant overhead field evenly allocated. Each sub-payload region is allocated 4 bytes of target area. When using the CRC32 algorithm, the 32-bit result can be directly carried without compression.

[0079] like Figure 16 As shown, the first region has 8 segments, with a 16-byte redundant overhead field. The payload area is divided into 8 segments (the first segment contains redundant padding bits + 315 code blocks, and the remaining segments each have 320 code blocks). The redundant overhead field is evenly allocated, and each sub-payload segment is allocated a 2-byte target area. When using the CRC32 algorithm, the 32-bit result needs to be compressed to 16 bits before being carried.

[0080] like Figure 17 As shown, the first region has 8 sections, with a redundant overhead field of 32 bytes. The payload area is divided into 8 sections (the first section contains redundant padding bits + 315 code blocks, and the remaining sections each have 320 code blocks), with an equal allocation of 32 bytes of redundant overhead field. Each sub-payload area is allocated 4 bytes of target area. When using the CRC32 algorithm, the 32-bit result can be directly carried without compression.

[0081] like Figure 18As shown, the first region has 4 regions, with a redundant overhead field of 16 bytes. The payload area is divided into 4 regions (the first region contains redundant padding bits + 635 code blocks, and the remaining regions each have 640 code blocks). The redundant overhead field is evenly allocated, and each sub-payload region is allocated a target region of 4 bytes. When using the CRC32 algorithm, the 32-bit result can be directly carried without compression.

[0082] In these alternative embodiments, the first sub-payload area carries the excess padding bits and P complete code blocks, while the remaining sub-payload areas contain only Q complete code blocks, ensuring that all 257-bit code blocks do not cross regions. This solves the padding bit carrying problem, accurately locates check errors, and simplifies the erroneous code block replacement process.

[0083] In one embodiment, the target area corresponding to each sub-net load area is determined in the following manner: Based on the target fixed-insertion code block and the number of second zones in all sub-payload zones of the N data frames, the target zone corresponding to each sub-payload zone in the target data frame is determined.

[0084] Optionally, in this embodiment, firstly, the configuration rules for the target fixed-insertion code block in a multiframe consisting of N data frames are defined. Each 257-bit fixed-insertion code block is split into a 256-bit data segment and a 1-bit reserve segment. Subsequently, the number of second regions in all sub-payload areas of the N data frames is counted (e.g., 16, 8, or 4). Based on this number, the 256-bit data segment of the fixed-insertion code block is allocated to each sub-payload area. For example, when the number of second regions is 16, each of the four sub-payload areas in each frame is allocated 256 / 16 = 16 bits of fixed-insertion code block data to carry the first check information.

[0085] In these alternative embodiments, the target is fixedly stuffed with code blocks, and the target area is allocated in combination with the number of second areas of N data frames, without having to occupy a large amount of additional bandwidth, thus reducing the overhead of target data frame transmission.

[0086] In one embodiment, determining the target region corresponding to each sub-payload region in the target data frame based on the target fixed-insertion code block and the number of second regions of all sub-payload regions in the N data frames includes: According to the second number of regions, the fixed inserted code blocks are allocated to each sub-payload region in the N data frames to obtain the target region corresponding to each sub-payload region in the target data frame.

[0087] Optionally, in this embodiment, firstly, the processing rules for the target fixed-insertion code block in a multiframe composed of N data frames are defined. Each 257-bit fixed-insertion code block is split into a 256-bit data segment and a 1-bit reserve segment. The 1-bit reserve segment is fixedly placed at a preset position in the Lo path payload area (such as the tail). This allocation method is to adapt to the transmission mechanism of FlexO Lopath frames. After splitting, the 256 bits can be evenly grouped according to the number of the second zone (such as 64 groups of 4 bits, 32 groups of 8 bits, etc.) to flexibly match the verification result carrying requirements of different partitions. Moreover, 256, as an integer power of 2, can be accurately split into equal-length groups, which is convenient to evenly distribute to each sub-payload area according to the number of the second zone (16, 8, 4), ensuring that the number of bits in the target area is consistent. At the same time, the 1-bit reserve segment is stripped separately as a redundant part to avoid interfering with the verification data processing, allowing the 256-bit data segment to focus on carrying the verification result and improving data transmission efficiency.

[0088] Optionally, in one specific implementation of this application, the number of second regions (the total number of all sub-payload regions in the multiframe, such as 64, 32, or 16) is determined, and the split 256-bit groups are evenly distributed to the end of the corresponding sub-payload regions in each frame of the multiframe. For example, when the number of second regions is 64 (4 frames × 16 sub-payload regions), each sub-payload region is allocated 4 bits of fixed-insertion code block data; when the number of second regions is 32 (4 frames × 8 sub-payload regions), each sub-payload region is allocated 8 bits of data; when the number of second regions is 16 (4 frames × 4 sub-payload regions), each sub-payload region is allocated 16 bits of data. These allocated fixed-insertion code block data areas are the target regions, used to carry the first check information.

[0089] In these alternative embodiments, fixed-insertion code blocks are reused, and the target area is evenly distributed according to the number of second areas of all sub-payload areas of N data frames, so as to efficiently carry the verification information and reduce the overhead of target data frame transmission.

[0090] In one embodiment, the step of allocating the fixed-insertion code blocks to each sub-payload region in the N data frames according to the second region number, to obtain the target region corresponding to each sub-payload region in the target data frame, includes: The target code block, which is fixedly inserted into the code block, is allocated to each sub-payload area in the N data frames according to the number of the second area.

[0091] Optionally, in this embodiment, the target code block refers to the data segment used to carry the first check information after splitting the fixed-insertion code block (a free 257-bit code block). Specifically, each 257-bit fixed-insertion code block can be split into a 256-bit data segment and a 1-bit spare segment (the 1-bit spare segment is fixedly placed at a preset position in the Lo path payload area and does not carry valid check information). This 256-bit data segment is the target code block. It should be noted that this application is not limited to the splitting method of the 256-bit data segment. It can also be split into other lengths of valid data segments (such as 128 bits, 64 bits, etc.) according to the check information carrying requirements. As long as it is a valid data segment used to carry the first check information after splitting the fixed-insertion code block, it is within the protection scope of this application.

[0092] Optional, in Figures 6-11 ,as well as Figures 13-18 The proposed scheme uses extra overhead bytes to carry the first checksum information, requiring additional overhead bytes and consuming bandwidth resources. In practical applications, the speed of the client's 257-bit code block stream is slightly less than the speed of the lo path frame container. Therefore, the container cannot be filled with 257-bit code blocks, and some 257-bit block positions are fixed-position code blocks. When the client's 257-bit code blocks are transferred to the lo path frame container, the carrying method is calculated every four frames (four consecutive frames constitute a multiframe). Based on the deviation between the client speed and the container speed, x (x is a natural number) fixed-position 257-bit code blocks are inserted into the container. The positions of x fixed-position 257-bit code blocks are calculated using the Sigma algorithm.

[0093] According to the standard, the x value of the fixed 257-bit code block is between 2 and 7. That is, there are at least 2 fixed 257-bit code blocks and at most 7 fixed 257-bit code blocks in every four frames. These fixed 257-bit code blocks only perform the idle stuffing function and do not carry any client information, which is somewhat wasteful. If the fixed 257-bit code blocks carry the first check information, then these fixed 257-bit code blocks will not only perform the fixed stuffing function, but also have the function of carrying the first check information, thus playing a more functional role.

[0094] However, the number of fixed 257-bit code blocks inserted into a multiframe composed of 4 frames is only 2-7, which is too few and inconsistent. Furthermore, each fixed 257-bit code block is too large (generally, the CRC32 algorithm is used, but the CRC result is only 32 bits, which is wasteful when carried in a 257-bit code block), making it unsuitable for directly carrying the CRC calculation result. Moreover, when the current client code block is mapped to the LoPah payload area, the Sigma algorithm is used to determine the position of the fixed 257-bit code block, resulting in an inconsistent position that varies with the number of fixed code blocks.

[0095] Therefore, this application improves the mapping mechanism by dividing the fixed 257-bit code block into two parts: 256 bits + 1 bit. The 256 bits are fixedly and evenly distributed within the payload area of ​​the Lo path, while the remaining 1 bit is fixedly placed at a fixed position within the Lo path payload area (e.g., the last position of the Lo path payload area, see...). Figures 19-21 (The remaining filling position in the middle).

[0096] like Figure 19 In the example, each fixed 257-bit code block has 256 bits divided into 64 groups of 4 bits each. These 64 groups are evenly distributed across a multiframe consisting of 4 frames. Each frame contains 16 groups of 4 bits, with each group of 4 bits located at the end of the 1 / 16th sub-payload area of ​​the Lo path payload region. When the number of fixed 257-bit code blocks is x, the end of the 1 / 16th sub-payload area of ​​the Lo path payload region contains x groups of 4 bits. These x groups of 4 bits are used consecutively to carry the CRC calculation result. Under the existing mapping mechanism, x is a value between 2 and 7, resulting in 8 to 28 bits used to store the CRC calculation result.

[0097] Therefore, after allocating a fixed 257-bit code block, the CRC value of each 1 / 16 sub-payload area is calculated, typically using the CRC32 algorithm to obtain a 32-bit CRC32 result. This 32-bit result is then compressed into x 4-bit segments (i.e., the first check information), which are carried in the x 4-bit positions at the end of the sub-payload area. At the receiving end (i.e., the second communication device), the CRC value in each sub-payload area is calculated using the same CRC algorithm. Based on the number of fixed 257-bit code blocks carried in the overhead, the CRC value calculated by the receiving end is compressed into x 4-bit segments and compared with the value carried in the x 4-bit positions at the end of the sub-payload area. If the comparison results are the same, it indicates that the sub-payload content is correct; if the comparison fails (the values ​​are different), it indicates that the sub-payload content is incorrect, and the sub-payload content is replaced with the erroneous code block. A 32-bit CRC value can be compressed into x 4-bit values. Compression algorithms include: 1. direct truncation, 2. polynomial remapping, 3. hybrid hashing, 4. table lookup conversion, etc. Any compression algorithm is within the scope of this application.

[0098] In practical implementation, each fixed 257-bit code block can be divided into 32 groups of 256 bits, with each group consisting of 8 bits (one byte). These 32 groups are evenly distributed across a multiframe consisting of 4 frames. Each frame contains 8 groups of 8 bits (one byte). One byte from each group is located at the end of the 1 / 8 sub-payload area of ​​the Lo path's payload region. The last position of this 1 / 8 sub-payload area contains x bytes used to carry the CRC result, such as... Figure 20 .

[0099] exist Figure 20 In this process, the size of each sub-payload area doubles, and the number of bits carrying the CRC result after the sub-payload area also doubles. The CRC calculation method and the CRC result are the same; only the size of the compressed CRC32 result is different.

[0100] In practical implementation, each fixed 257-bit code block can be divided into 16 groups of 256 bits, each group consisting of 16 bits (2 bytes). These 16 groups are evenly distributed across a multiframe consisting of 4 frames. Each frame contains 4 groups of 16 bits (2 bytes). Each group of 16 bits (2 bytes) is located at the end of the 1 / 4 sub-payload area of ​​the Lo path payload region. The last position of this 1 / 4 sub-payload area contains x 16 bits used to carry the CRC result, such as... Figure 21 .exist Figure 21 In the middle, each sub-net load area is compared to Figure 18 The number of bits carrying the CRC result increases fourfold, and the number of bits after the sub-payload area also increases fourfold. The CRC calculation method and the carrying of the CRC result are the same. Since the x value is in the range of 2-7, the last position of the 1 / 4 sub-payload area of ​​the Lo path has 32-112 bits (which can carry the CRC32 result, with at least 32 bits to carry the CRC32 bit calculation result, so there is no need to compress the CRC32 bit calculation result).

[0101] In these alternative embodiments, the target code block with fixed insertion is multiplexed and allocated to each sub-payload area according to the number of second areas of all sub-payload areas in N data frames to determine the target area, without requiring additional bandwidth.

[0102] In one embodiment, the target area corresponding to each sub-net load area is determined in the following manner: Based on the overhead field and the number of first zones in the multiple sub-payload zones in the target data frame, determine the first sub-zone corresponding to each sub-payload zone in the target data frame; Based on the target fixed-insertion code block and the number of second regions of all sub-payload regions in the N data frames, determine the second sub-region corresponding to each sub-payload region in the target data frame; The target area corresponding to each sub-load area in the target data frame is obtained based on the first sub-area corresponding to each sub-load area in the target data frame and the second sub-area corresponding to each sub-load area in the target data frame.

[0103] Optionally, in this embodiment, the first sub-region is determined based on the overhead field and the number of first regions in multiple sub-payload regions in the target data frame, corresponding to the related implementation method of "using the overhead field alone" mentioned above. Specifically, the excess overhead fields of the target data frame are evenly distributed to the end of each sub-payload region according to the number of first regions, and the portion of the overhead field corresponding to each sub-payload region is the first sub-region.

[0104] The second sub-region is determined based on the number of second regions in all sub-payload regions within a multiframe consisting of a target fixed-insertion code block and N data frames, corresponding to the previous implementation method of "individually adapting to fixed-insertion code blocks". Specifically, the target fixed-insertion code block is split into a 256-bit data segment (target code block) and a 1-bit reserve segment (fixed in a preset position in the payload region). The 256-bit data segment is then evenly distributed to the end of each sub-payload region of each data frame in the multiframe according to the number of second regions. The fixed-insertion code block grouping area corresponding to each sub-payload region is the second sub-region.

[0105] Optionally, in the embodiments of this application, the first sub-region and the second sub-region can be merged in various ways to form a complete target region. Specific combination methods include not only splicing the two sub-regions one after the other, but also bit interleaving (alternating the bits of the first and second sub-regions in a preset order), segmented carrying (the first sub-region carries the high-order bits of the first check information, and the second sub-region carries the low-order bits of the first check information), etc. This application is not limited to the above combination methods. Any implementation method that determines the first sub-region based on the overhead field and the number of first regions, determines the second sub-region based on the target fixed-insertion code blocks and the number of second regions, and then obtains the target region to carry the first check information through any reasonable fusion method, is within the protection scope of this application.

[0106] In these alternative embodiments, the first sub-region and the second sub-region are determined by combining the overhead field and the target fixed-insertion code block, and then the target region is formed based on the first and second sub-regions. This approach avoids the need for excessive bandwidth usage, flexibly adapts to different partition configurations, and improves the capacity for carrying verification information and the reliability of transmission.

[0107] In one embodiment, obtaining the target area corresponding to each sub-payload area in the target data frame based on the first sub-area corresponding to each sub-payload area in the target data frame and the second sub-area corresponding to each sub-payload area in the target data frame includes: For any sub-payload region in the target data frame, the first sub-region corresponding to the sub-payload region and the second sub-region corresponding to the sub-payload region are combined to obtain the target region corresponding to the sub-payload region.

[0108] Optionally, in the embodiments of this application, in Figures 6-11 ,as well as Figures 13-18The scheme uses a redundant overhead field to carry the CRC calculation result. Figures 19-21 The CRC calculation result is carried by using a portion of the bits of a fixed 257-bit code block. In a specific implementation, the overhead field and a portion of the bits of the free 257-bit code block can be combined to carry the CRC calculation result. In this way, only a small amount of overhead field is needed to carry more CRC results.

[0109] like Figure 22 As shown, Figure 22 A 16-byte overhead field is used to divide the payload area of ​​the Lo path into 16 evenly distributed sub-payload areas. The 256 bits in the 257-bit free code block are divided into 64 groups, with 16 groups per frame. In the diagram, the slashed background units represent the overhead field, with each sub-payload area being 1 byte (8 bits). The black background units represent bits from fixed-insertion code blocks. Each fixed-insertion code block corresponds to 4 bits; x fixed-insertion code blocks (x between 2 and 7) result in x 4-bit blocks; 2-7 fixed-insertion code blocks result in 8-28 bits. Adding the 8 bits from the overhead field, a total of 16-36 bits are available to carry the CRC value. When the total number of bits is less than 32, the calculated CRC32 result is compressed to the number of bits that can be carried before transmission. Combining the overhead field with bits from the 257-bit fixed-insertion code blocks to carry the CRC calculation result results in a larger number of bits for the CRC result.

[0110] Apart from Figure 22 In addition to using a 16-byte overhead field to carry the CRC result, a 32-byte overhead field can also be used, such as... Figure 23 The payload area of ​​the Lo path is divided into 16 evenly distributed sub-payload areas. The 256 bits fixed in the code block are divided into 64 groups, with 16 groups per frame. In the diagram, the slash background unit is the overhead field. Each sub-payload area is 2 bytes (16 bits in total). The black background unit is a portion of the bits of the fixed code block. Each fixed code block corresponds to 4 bits. x free code blocks (x is between 2 and 7) have x 4-bit blocks. When there are 2-7 free code blocks, there are 8-28 bits. Adding the 16 bits of the overhead field, there are a total of 24-42 bits that can carry the CRC value. When the total number of bits is less than 32 bits, the calculated CRC32 result is compressed to the number of bits that can be carried before being carried.

[0111] exist Figure 22 , Figure 23 The Lo path's payload area is divided into 16 uniform sub-payload areas. Alternatively, in implementation, the Lo path's payload area can be divided into 8 uniform sub-payload areas. Figure 22 The transformation Figure 24The overhead field uses 16 bytes to divide the payload area of ​​the Lo path into 8 evenly distributed sub-payload areas. The 256 bits in the fixed-insertion code block are divided into 32 groups, with 8 groups per frame. In the diagram, the slash background unit is the overhead field, and each sub-payload area is 2 bytes (16 bits). The black background unit is a portion of the bits in the fixed-insertion code block. Each fixed-insertion code block corresponds to 8 bits. x fixed-insertion code blocks (x is between 2 and 7) result in x 8-bit blocks. When there are 2-7 fixed-insertion code blocks, there are 16-56 bits. Adding the 16 bits of the overhead field, there are a total of 32-72 bits that can carry the CRC value, which is sufficient to carry the CRC32 result without the need to compress the CRC32 result.

[0112] In these alternative embodiments, the target area is obtained by combining the first sub-region and the second sub-region, which reuses redundant overhead fields and fixed stuffing code blocks, reduces additional bandwidth usage, and increases the capacity to carry verification information.

[0113] In one embodiment, the target data frame includes a first sub-payload area and a second sub-payload area; the target area corresponding to each sub-payload area is determined in the following manner: The target area corresponding to the first sub-net load area is determined based on the first information; The target area corresponding to the second sub-net load area is determined based on the second information; Wherein, the first information is one of the overhead field of the target data frame and the target fixed-insertion code block corresponding to the target data frame; the second information is the other of the overhead field of the target data frame and the target fixed-insertion code block corresponding to the target data frame.

[0114] Optionally, in one specific implementation of this application, firstly, the frame structure configuration of the target data frame (such as a Flex0 100 path frame) is defined, and the payload area of ​​the target data frame is divided into two sub-payload areas, namely the first sub-payload area and the second sub-payload area (the division ratio can be set according to actual needs, such as a 1:1, 2:1 ratio, or a fixed number, such as the first 8 being the first sub-payload area and the last 8 being the second sub-payload area). For the first sub-payload area, its corresponding target area is determined based on the first information (here, the overhead field of the target data frame is selected): according to the number of first sub-payload areas in the target data frame, the overhead field is evenly distributed to the end of each first sub-payload area according to the number, and the portion of the overhead field corresponding to each first sub-payload area is its target area, which is used to carry the first verification information of the first sub-payload area.

[0115] For the second sub-payload area, its corresponding target area is determined based on the second information (here, the target fixed-insertion code block is selected): First, each 257-bit fixed-insertion code block is split into a 256-bit data segment (target code block) and a 1-bit reserve segment. The 1-bit reserve segment is fixedly placed at a preset position in the Lo path payload area (such as the tail). Then, according to the total number of all second sub-payload areas in the multiframe composed of N data frames, the 256-bit data segment is evenly distributed to the tail of each second sub-payload area in each data frame of the multiframe. This part of the grouped area is the target area of ​​the second sub-payload area, used to carry the first check information of the second sub-payload area. This application can flexibly adjust the division method of the first and second sub-payload areas, the configuration of the overhead field, and the group length of the fixed-insertion code block. As long as the implementation method of determining the target area based on the overhead field for part of the sub-payload area and the fixed-insertion code block for the other part is within the scope of protection.

[0116] In these alternative embodiments, the first and second sub-payload areas are divided, and the target area is determined based on the overhead field and the target fixed-insertion code block, respectively. This does not require a large amount of additional bandwidth, adapts to the needs of different business scenarios, and ensures the reliability of data transmission.

[0117] In one embodiment, the first verification information corresponding to each sub-load area is determined in the following manner: For any sub-load area, perform a verification operation on the sub-load area to obtain the initial verification information corresponding to the sub-load area; Based on the initial verification information and the target area corresponding to the sub-net load area, the first verification information corresponding to the sub-net load area is determined.

[0118] Optionally, in this embodiment, firstly, for any sub-payload area divided in the target data frame, a verification operation is performed on the 257-bit code block data within that sub-payload area. The verification algorithm can be CRC32, CRC16, CRC24, etc. (CRC32 is used as an example in this embodiment). By performing verification calculations on the valid data of all 257-bit code blocks, 32 bits of initial verification information are obtained. Subsequently, the first verification information is determined based on the characteristics of the target area corresponding to the sub-payload area. The core is to make the first verification information compatible with the carrying capacity of the target area. Specific implementation methods include at least the following multiple implementation methods: 1. If the target area is 8 bits (1 byte), the 32-bit initial check information is compressed into 8 bits using compression algorithms such as direct truncation and polynomial remapping, and used as the first check information; if the target area is 32 bits (4 bytes), the initial check information is directly used as the first check information without compression.

[0119] 2. If the target area consists solely of the overhead field, the key bit segment that retains the initial verification information can be selected as the first verification information based on the stability of the overhead field.

[0120] 3. To improve reliability, redundant check bits of the initial check information can be added to the initial check information based on the remaining carrying space of the target area to obtain the first check information.

[0121] This application is not limited to the above-mentioned methods. Any implementation that obtains the first verification information based on the initial verification information of the sub-load area and the target area after adaptation processing is within the scope of protection.

[0122] In these alternative embodiments, initial verification information is first obtained by performing verification on each sub-payload area, and then first verification information is generated by adapting the target area characteristics to ensure the effective carrying of the first verification information and improve the reliability of data transmission.

[0123] In one embodiment, determining the first verification information corresponding to the sub-load area based on the initial verification information and the target area corresponding to the sub-load area includes: If the number of bits in the initial verification information is greater than the number of bits that the target area corresponding to the sub-payload area can bear, the initial verification information is compressed to obtain the first verification information corresponding to the sub-payload area. If the number of bits in the initial verification information is less than or equal to the number of bits that the target area corresponding to the sub-payload area can carry, the initial verification information shall be used as the first verification information corresponding to the sub-payload area.

[0124] Optionally, in one specific implementation of this application, firstly, the initial verification information of the sub-payload area is obtained (which can be calculated using CRC algorithms such as CRC32 and CRC16, or generated from encryption parameters when encryption is enabled), and the number of bits that the target area can carry corresponding to the sub-payload area is determined. Then, a bit count comparison is performed: if the number of bits in the initial verification information is greater than the number of bits that the target area can carry (for example, a 32-bit CRC32 result corresponds to an 8-bit carrying capacity in the target area, or a 128-bit authentication value corresponds to a 48-bit carrying capacity in the target area), a compression algorithm such as direct truncation, polynomial remapping, hybrid hashing, or table lookup conversion is used to compress the initial verification information to the number of bits that the target area can carry; the compressed result is the first verification information. If the number of bits in the initial verification information is less than or equal to the number of bits that the target area can carry (for example, a 32-bit CRC32 result corresponds to a carrying capacity of 32 bits or more in the target area), no additional processing is required, and the initial verification information is directly used as the first verification information. Finally, the first verification information is stored in the target area, completing the adaptation and carrying of the verification information.

[0125] In these alternative embodiments, the initial verification information is flexibly adapted to the number of bits that the target area can carry: if the number of bits exceeds the limit, it is adapted through compression; if it does not exceed the limit, it is directly reused. This adapts to the carrying capacity of different target areas, ensures that the verification information is effectively carried, and guarantees the reliability of data transmission.

[0126] In one embodiment, compressing the initial verification information to obtain the first verification information corresponding to the sub-payload area includes: The bit sequence of the initial verification information is divided into K bit groups, where K is the number of bits in the first verification information; Perform an XOR operation on multiple bits within each bit group to obtain the result bits corresponding to the bit group; The first verification information is obtained by combining the K result bits corresponding to the K bit groups.

[0127] Optionally, in one specific implementation of this application, the bit length of the initial verification information (e.g., 32 bits for CRC32) and the target number of bits K of the first verification information are first determined (determined by the number of bits that the target area of ​​the sub-payload zone can carry, such as 8 bits, 16 bits, etc.). The number of bits contained in each bit group is calculated (i.e., the ratio of the number of bits of the initial verification information to K; for example, when 32-bit CRC32 is compressed to 8 bits, each bit group contains 4 bits). Then, the bit sequence of the initial verification information is divided into K non-overlapping bit groups according to the uniform interval rule, ensuring that the number of bits in each group is consistent and covers all the initial bits. Next, an XOR operation is performed on all bits in each bit group to generate a 1-bit result bit. For example, when 32-bit CRC32 is compressed to 8 bits (CRC8), the specific operation is as follows: CRC8[7] = {CRC32

[31] ⊕ CRC32

[23] ⊕ CRC32

[15] ⊕ CRC32[7]}; CRC8[6] = {CRC32

[30] ⊕ CRC32

[22] ⊕ CRC32

[14] ⊕ CRC32[6]}; CRC8[5] = {CRC32

[29] ⊕ CRC32

[21] ⊕ CRC32

[13] ⊕ CRC32[5]}; CRC8[4] = {CRC32

[28] ⊕ CRC32

[20] ⊕ CRC32

[12] ⊕ CRC32[4]}; CRC8[3] = {CRC32

[27] ⊕ CRC32

[19] ⊕ CRC32

[11] ⊕ CRC32[3]}; CRC8[2] = {CRC32

[26] ⊕ CRC32

[18] ⊕ CRC32

[10] ⊕ CRC32[2]}; CRC8[1] = {CRC32

[25] ⊕ CRC32

[17] ⊕ CRC32[9]⊕ CRC32[1]}; CRC8[0] = {CRC32

[24] ⊕ CRC32

[16] ⊕ CRC32[8]⊕ CRC32[0]}; Finally, according to the order of each bit group in the initial sequence, the K result bits are combined sequentially to form the first verification information.

[0128] In these alternative embodiments, the initial verification information is adapted to the target area by bit group partitioning and XOR operation, which can flexibly match the bit number requirements of the target area, and the compression process is efficient and low-power.

[0129] In one embodiment, the first verification information corresponding to each sub-load area is determined based on at least one of the following: The cyclic redundancy check value corresponding to the data in the sub-net load area; The authentication value corresponding to the data in the sub-load area.

[0130] Optionally, in this embodiment of the application, the first communication device divides the payload area of ​​the Lo path into multiple sub-payload areas, and the first verification information corresponding to each sub-payload area is determined based on at least one of the CRC value and the authentication value corresponding to the data in the sub-payload area.

[0131] Specifically, when encryption is not enabled, the first communication device can perform CRC calculation on all bit data or 257-bit code block bit data in the sub-payload area, and store the obtained CRC value as the first verification information in the corresponding bearer location of the sub-payload area; the second communication device performs the same CRC calculation, compares the result with the first verification information carried in the Lo path frame, if the comparison is consistent, it means that the content of the sub-payload area is correct, if the comparison fails, the 257-bit code block of the sub-payload area needs to be replaced with the erroneous code block.

[0132] In practical applications, if encryption of the Lo path payload is required, the first communication device divides the Lo path payload area into multiple sub-payload areas. It encrypts the content of each sub-payload area using an encryption algorithm and stores it in the corresponding area. Simultaneously, it generates an authentication tag (AT) based on the encrypted sub-payload bit content and encryption parameters, and uses this authentication tag as the first verification information. The second communication device decrypts the sub-payload content using the same encryption algorithm and generates an authentication tag according to the same rules. It compares this authentication tag with the first verification information (authentication tag) carried in the frame: if the comparison matches, the sub-payload content is validly encrypted and can be decrypted to obtain the original client content; if the comparison does not match, the sub-payload content contains errors or is not validly encrypted, and the sub-payload bit content is discarded without performing decryption.

[0133] The authentication value indirectly achieves the core purpose of the CRC function. When the content of the sub-payload area is corrupted during transmission, the authentication value generated by the second communication device will inevitably be inconsistent with the carried authentication value. By discarding the erroneous content, the problem of misreception can be avoided, naturally meeting the MTTFPA requirements. After enabling the encryption function, there is no need to enable the CRC function separately. Since the authentication value generated by the encryption algorithm is usually 128 bits, much larger than the 32 bits of the common CRC32, compression algorithms such as direct truncation, polynomial remapping, hybrid hashing, and table lookup transformation can be used to compress the original authentication value before carrying it.

[0134] In these alternative embodiments, it is supported to determine the first verification information based on the CRC value or the authentication value, adapting to unencrypted and encrypted scenarios, flexibly adapting to different business needs, and ensuring the reliability of data transmission.

[0135] The data processing method provided in the second aspect of this application will be described in detail below with reference to the accompanying drawings and through some embodiments and application scenarios.

[0136] See Figure 25 , Figure 25 This is a schematic flowchart of the data processing method provided in the second aspect of this application.

[0137] like Figure 25 As shown, the data processing method is applied to a second communication device, and the method includes, but is not limited to, the following steps: S2501, Receive a target data frame sent by a first communication device, wherein the target data frame includes multiple sub-payload areas and first verification information corresponding to each sub-payload area in the multiple sub-payload areas; S2502, Process each sub-net load area according to the first verification information corresponding to each sub-net load area.

[0138] The explanations of the relevant terms can be found in the explanations of the foregoing embodiments, and will not be repeated here.

[0139] In this embodiment, multiple sub-payload areas are set in the target data frame, and corresponding first verification information is configured for each sub-payload area. The division of the data frame into multiple independent transmission and verification units by these sub-payload areas directly associates the first verification information of each sub-payload area with the data carried within that sub-payload area. This achieves precise binding between verification information and data, ensuring comprehensive and targeted verification coverage. Regardless of any format differences between the Flex0 100 path frame structure and traditional networks, the verification mechanism can be adapted to the frame structure through the combination of sub-payload areas and corresponding first verification information. This makes the service layer's verification of client data streams universal and effective, thereby solving the problem of insufficient transmission reliability caused by the lack of a verification information carrying mechanism in the service layer and improving the reliability of data transmission.

[0140] In one embodiment, processing each sub-load area according to the first verification information corresponding to each sub-load area includes: Perform a verification operation on the data in each sub-net load area to obtain the second verification information corresponding to each sub-net load area; Each sub-load area is processed based on the first verification information and the second verification information corresponding to each sub-load area.

[0141] Optionally, in this embodiment, the second verification information is the verification result obtained by the receiving end after performing verification operations on the data in each sub-payload area, and it is consistent with the verification method used by the sending end to generate the first verification information. For each sub-payload area, the receiving end extracts the data within the area, recalculates according to the same verification rules as the sending end, and the corresponding length verification result obtained is the second verification information, which is used to compare with the first verification information to determine whether there are errors in the sub-payload area data during transmission.

[0142] Optionally, in one specific implementation of this application, the second communication device first acquires the data of each sub-payload area in the target data frame, and performs a verification operation according to the rules consistent with the first verification information generated by the first communication device.

[0143] In unencrypted scenarios, the same CRC algorithm is used; in encrypted scenarios, the same authentication value generation mechanism is used to calculate the second check information corresponding to each sub-payload area. Then, the first check information and the second check information of each sub-payload area are compared bit by bit: if they match, it means that no errors occurred during the transmission of the sub-payload data, and the 257-bit code block data of that sub-payload area is directly transmitted downstream without additional processing; if they do not match, it indicates that there are errors in the data transmission, and all 257-bit code blocks corresponding to that sub-payload area need to be replaced with preset error code blocks, and the error code blocks are discarded to prevent erroneous data from continuing to flow.

[0144] In these alternative embodiments, the second verification information is first calculated using rules consistent with those of the first communication device, and then compared with the first verification information to avoid erroneous reception of messages, effectively reduce the probability of missed detection, and ensure the reliability of data transmission.

[0145] In one embodiment, processing each sub-load area based on the first verification information and the second verification information corresponding to each sub-load area includes: For any sub-load area, if the first verification information corresponding to the sub-load area and the second verification information corresponding to the sub-load area do not match, the data in the sub-load area shall be discarded.

[0146] Optionally, in one specific implementation of this application, the second communication device performs a bit-by-bit precise comparison between the first verification information and the second verification information for each sub-payload area. If the comparison results do not match, it indicates that there are abnormalities such as bit errors or tampering in the data transmission. In order to avoid the erroneous data affecting subsequent processing, all 257-bit code block data in the sub-payload area are directly discarded without decryption (or, in the case of encryption) or transmission downstream.

[0147] In other implementations, if the comparison results do not match, the second communication device does not directly discard the data. Instead, it replaces all 257-bit code blocks in the sub-payload area with preset error code blocks, preserving the code block's position occupancy and frame structure integrity. Subsequent downstream processing modules, upon detecting the error code block marker, can choose to discard the entire frame, trigger a retransmission request, or perform error statistics according to business rules. This avoids the flow of erroneous data while maintaining frame structure stability.

[0148] In these alternative embodiments, the sub-payload data is directly discarded when the first and second verification information do not match, which can quickly block the flow of erroneous data. This avoids the misreceipt and misprocessing of erroneous messages, effectively reduces the risk of missed detections, and ensures the accuracy and reliability of transmission.

[0149] In one embodiment, processing each sub-load area based on the first verification information and the second verification information corresponding to each sub-load area includes: If a portion of the target code block's bit content exists in the i-th sub-payload area, and the remaining bit content of the target code block exists in the (i+1)-th sub-payload area, and the first check information corresponding to the i-th sub-payload area and the second check information corresponding to the i-th sub-payload area do not match, then the data in the i-th sub-payload area and the (i+1)-th sub-payload area shall be discarded.

[0150] Optionally, in one specific implementation of this application, the second communication device first extracts all data from the i-th sub-payload area and the (i+1)-th sub-payload area in the target data frame to determine whether there is a target 257-bit code block spanning the two areas (i.e., some bits of the target code block are located in the i-th sub-payload area, and the remaining bits are located in the (i+1)-th sub-payload area). Then, according to the same verification rules as the first communication device, verification operations are performed on the data in the i-th sub-payload area and the (i+1)-th sub-payload area respectively to obtain their corresponding second verification information. Next, the first verification information and the second verification information of the i-th sub-payload area are compared: if the comparison does not match, regardless of whether the verification results of the (i+1)-th sub-payload area are consistent, it is determined that the target 257-bit code block spanning the two areas has a transmission error. To avoid the flow of erroneous data, all data in the i-th sub-payload area and the (i+1)-th sub-payload area are directly discarded, and neither downstream transmission nor decryption operation is performed (in the case of encryption).

[0151] In these alternative embodiments, for target code blocks spanning the i-th and i+1-th sub-payload areas, if the checksum of the i-th sub-payload area does not match, the data in both sub-payload areas is directly discarded. This completely avoids the problem of cross-area code blocks not being detected due to partial bit errors, prevents erroneous data from flowing, effectively reduces the probability of missed detections, and ensures the accuracy of transmission.

[0152] It should be noted that the various embodiments described in this application can be combined with each other or implemented individually without conflict, and this application does not limit this.

[0153] This application also provides an electronic device, such as... Figure 26 As shown, the electronic device 2600 includes: One or more processors 2610; The memory 2620 stores one or more programs that, when executed by one or more processors 2610, cause the one or more processors 2610 to implement the data processing method as described in the first aspect, or the data processing method as described in the second aspect.

[0154] Memory 2620, as a non-transitory network system, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory 2620 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 2620 may optionally include remotely located memories 2620 relative to processor 2610, which can be connected to processor 2610 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0155] The memory 2620 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 2620 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 2620 and is called and executed by the processor 2610.

[0156] The processor 2610 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0157] In some embodiments, the electronic device further includes: Input / output interfaces are used to implement information input and output; The communication interface is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). The bus transmits information between various components of the device (e.g., processor 2610, memory 2620, input / output interface, and communication interface); The processor 2610, memory 2620, input / output interface, and communication interface can communicate with each other within the device via a bus.

[0158] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions for performing the data processing method as described in the first aspect, or the data processing method as described in the second aspect.

[0159] An embodiment of this application also provides a computer program product, including a computer program or computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions to cause the computer device to perform the data processing method as described in the first aspect or the data processing method as described in the second aspect.

[0160] The system architecture and application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that as system architectures evolve and new application scenarios emerge, the technical solutions provided in this application are also applicable to similar technical problems.

[0161] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0162] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0163] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process or execution thread, and components may be located on a single computer or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, or a network, such as the Internet interacting with other systems via signals).

[0164] The above description, with reference to the accompanying drawings, illustrates some embodiments of this application, but does not limit the scope of this application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of this application shall be within the scope of this application.

Claims

1. A data processing method applied to a first communication device, the method comprising: A target data frame is sent to a second communication device, wherein the target data frame includes multiple sub-payload areas and first verification information corresponding to each of the multiple sub-payload areas.

2. The method according to claim 1, characterized in that, The first verification information corresponding to each sub-net load area is carried in the target area corresponding to each sub-net load area; The target area corresponding to each sub-net load area is determined based on at least one of the following: The overhead field of the target data frame; The target fixed stuffing code block corresponding to the target data frame; The target fixed-insertion code block is a fixed-insertion code block configured for N data frames, where N is an integer greater than 1, and the N data frames include the target data frame.

3. The method according to claim 2, characterized in that, The target area corresponding to each sub-net load area is determined in the following way: Based on the overhead configuration of the overhead field of the target data frame, the target area corresponding to each sub-payload area is determined; the overhead configuration is used to indicate whether there are redundant overhead fields that exceed the basic functions of the overhead field.

4. The method according to claim 3, characterized in that, Based on the overhead configuration of the overhead field of the target data frame, the target area corresponding to each sub-payload area is determined; The overhead configuration includes: When the overhead configuration indicates that the overhead field has the redundant overhead field, the target area is determined based on at least one of the following: the redundant overhead field, the target fixed stuffing code block corresponding to the target data frame; When the overhead configuration indicates that the overhead field does not contain the redundant overhead field, the target area is determined based on the target fixed insert code block corresponding to the target data frame.

5. The method according to claim 2, characterized in that, The target area corresponding to each sub-net load area is determined in the following way: Based on the overhead field and the number of first zones in the multiple sub-payload zones in the target data frame, the target zone corresponding to each sub-payload zone in the target data frame is determined.

6. The method according to claim 5, characterized in that, The step of determining the target area corresponding to each sub-payload area in the target data frame based on the overhead field and the number of first areas in the multiple sub-payload areas in the target data frame includes: Based on the number of the first area, the redundant overhead fields in the overhead fields are allocated to each of the sub-payload areas in the target data frame to obtain the target area corresponding to each sub-payload area in the target data frame; the redundant overhead fields are the extra fields in the overhead fields that exceed the basic functions of the overhead fields.

7. The method according to claim 2, characterized in that, The target area corresponding to each sub-net load area is determined in the following way: Based on the target fixed-insertion code block and the number of second zones in all sub-payload zones of the N data frames, the target zone corresponding to each sub-payload zone in the target data frame is determined.

8. The method according to claim 7, characterized in that, The step of determining the target region corresponding to each sub-payload region in the target data frame based on the target fixed-insertion code block and the number of second regions in all sub-payload regions of the N data frames includes: According to the second number of regions, the fixed inserted code blocks are allocated to each sub-payload region in the N data frames to obtain the target region corresponding to each sub-payload region in the target data frame.

9. The method according to claim 8, characterized in that, The step of allocating the fixed-insertion code blocks to each sub-payload area in the N data frames according to the second area quantity, to obtain the target area corresponding to each sub-payload area in the target data frame, includes: The target code block, which is fixedly inserted into the code block, is allocated to each sub-payload area in the N data frames according to the number of the second area.

10. The method according to claim 2, characterized in that, The target area corresponding to each sub-net load area is determined in the following way: Based on the overhead field and the number of first zones in the multiple sub-payload zones in the target data frame, determine the first sub-zone corresponding to each sub-payload zone in the target data frame; Based on the target fixed-insertion code block and the number of second regions of all sub-payload regions in the N data frames, determine the second sub-region corresponding to each sub-payload region in the target data frame; The target area corresponding to each sub-load area in the target data frame is obtained based on the first sub-area corresponding to each sub-load area in the target data frame and the second sub-area corresponding to each sub-load area in the target data frame.

11. The method according to claim 10, characterized in that, The step of obtaining the target area corresponding to each sub-payload area of ​​the target data frame based on the first sub-area corresponding to each sub-payload area in the target data frame and the second sub-area corresponding to each sub-payload area in the target data frame includes: For any sub-payload region in the target data frame, the first sub-region corresponding to the sub-payload region and the second sub-region corresponding to the sub-payload region are combined to obtain the target region corresponding to the sub-payload region.

12. The method according to claim 2, characterized in that, The target data frame includes multiple sub-payload areas, including a first sub-payload area and a second sub-payload area; the target area corresponding to each sub-payload area is determined in the following manner: The target area corresponding to the first sub-net load area is determined based on the first information; The target area corresponding to the second sub-net load area is determined based on the second information; Wherein, the first information is one of the overhead field of the target data frame and the target fixed-insertion code block corresponding to the target data frame; the second information is the other of the overhead field of the target data frame and the target fixed-insertion code block corresponding to the target data frame.

13. The method according to claim 1, characterized in that, In the target data frame, the size of the first sub-payload area is configured to accommodate the extra padding bits and P complete code blocks of the multiple sub-payload areas, and the remaining sub-payload areas are configured to accommodate Q complete code blocks; P and Q are both positive integers.

14. The method according to claim 1, characterized in that, The first verification information corresponding to each sub-net load area is determined in the following manner: For any sub-load area, perform a verification operation on the sub-load area to obtain the initial verification information corresponding to the sub-load area; Based on the initial verification information and the target area corresponding to the sub-net load area, the first verification information corresponding to the sub-net load area is determined.

15. The method according to claim 14, characterized in that, The step of determining the first verification information corresponding to the sub-load area based on the initial verification information and the target area corresponding to the sub-load area includes: If the number of bits in the initial verification information is greater than the number of bits that the target area corresponding to the sub-payload area can bear, the initial verification information is compressed to obtain the first verification information corresponding to the sub-payload area. If the number of bits in the initial verification information is less than or equal to the number of bits that the target area corresponding to the sub-payload area can carry, the initial verification information shall be used as the first verification information corresponding to the sub-payload area.

16. The method according to claim 15, characterized in that, The step of compressing the initial verification information to obtain the first verification information corresponding to the sub-payload area includes: The bit sequence of the initial verification information is divided into K bit groups, where K is the number of bits in the first verification information; Perform an XOR operation on multiple bits within each bit group to obtain the result bits corresponding to the bit group; The first verification information is obtained by combining the K result bits corresponding to the K bit groups.

17. The method according to claim 1, characterized in that, The first verification information corresponding to each sub-net load area is determined based on at least one of the following: The cyclic redundancy check value corresponding to the data in the sub-net load area; The authentication value corresponding to the data in the sub-load area.

18. A data processing method applied to a second communication device, the method comprising: Receive a target data frame sent by a first communication device, wherein the target data frame includes multiple sub-payload areas and first verification information corresponding to each sub-payload area; Each sub-load area is processed based on the first verification information corresponding to each sub-load area.

19. The method according to claim 18, characterized in that, The step of processing each sub-load area according to the first verification information corresponding to each sub-load area includes: Perform a verification operation on the data in each sub-net load area to obtain the second verification information corresponding to each sub-net load area; Each sub-load area is processed based on the first verification information and the second verification information corresponding to each sub-load area.

20. The method according to claim 19, characterized in that, The step of processing each sub-load area based on the first verification information and the second verification information corresponding to each sub-load area includes: For any sub-load area, if the first verification information corresponding to the sub-load area and the second verification information corresponding to the sub-load area do not match, the data in the sub-load area shall be discarded.

21. The method according to claim 19, characterized in that, The step of processing each sub-load area based on the first verification information and the second verification information corresponding to each sub-load area includes: If a portion of the target code block's bit content exists in the i-th sub-payload area, and the remaining bit content of the target code block exists in the (i+1)-th sub-payload area, and the first check information corresponding to the i-th sub-payload area and the second check information corresponding to the i-th sub-payload area do not match, then the data in the i-th sub-payload area and the (i+1)-th sub-payload area shall be discarded.

22. An electronic device, comprising: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to perform the following: The data processing method according to any one of claims 1-17, or the data processing method according to any one of claims 18-21.

23. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to perform the following: The data processing method according to any one of claims 1-17, or the data processing method according to any one of claims 18-21.

24. A computer program product comprising a computer program, which, when executed by a processor, implements, as follows: The data processing method according to any one of claims 1-17, or the data processing method according to any one of claims 18-21.

Images