Service processing method, network device, and storage medium
By transcoding and mapping the 66-bitcode block stream into a transmission container including overhead code blocks and time slot code blocks, the problem of excessive number of time slots in the high-speed Ethernet interface is solved, which improves data processing efficiency and reduces processing circuit costs.
Patent Information
- Application Number
- PCT/CN2024/122151
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-03
- Filing Date
- 2024-09-29
- Publication Date
- 2025-07-10
AI Technical Summary
In high-speed Ethernet interfaces such as 800Gbit/s, the FlexE protocol performs data processing in the way that 66 bitcode blocks are transmitted per time slot leads to excessive number of processing slots, reducing data processing efficiency, and intermediate devices need to perform two code block encoding format conversions, increasing processing circuit cost.
After 64B/66B encoding, the 66-bit code block stream is transcoded to generate a first code block stream with more bits, and map it to a transmission container including overhead code blocks and time slot code blocks. The overhead code blocks carry overhead information, and the time slot code block carries service information, increasing the transmission bandwidth of a single time slot, and reducing the number of processing time slots.
Improve data processing efficiency, reduce processing circuit costs, and reduce the number of processing time slots by unifying the code block format between the high-speed Ethernet interface and the FlexE protocol layer.
Smart Images

Figure CN2024122151_10072025_PF_FP_ABST
Abstract
Description
Business processing method, network equipment and storage medium
[0001] Cross-references
[0002] This application claims priority to a Chinese patent application filed with the Patent Office of China on January 3, 2024, with application number 202410009200.7 and invention name “Business processing method, network device and storage medium”. The entire contents of the application are incorporated by reference into this application. Technical Field
[0003] The embodiments of the present application relate to, but are not limited to, the field of communication technology, and in particular to a service processing method, a network device, and a storage medium. Background Art
[0004] The current FlexE (Flex Ethernet) standard specifies that each time slot transmits a 66-bit code block, representing a 5 Gbit / s transmission rate. Currently, data processing on high-speed Ethernet interfaces, such as 800 Gbit / s, is based on transmitting 257-bit code blocks per time slot. If, at 800 Gbit / s, the FlexE protocol still processes data using a 66-bit code block per time slot, i.e., processing data at a 5 Gbit / s transmission rate per time slot, the number of time slots processed will be very large, reducing data processing efficiency.
[0005] Summary of the Invention
[0006] The embodiments of the present application provide a service processing method, a network device, and a storage medium.
[0007] On the one hand, an embodiment of the present application provides a method for processing a service, including: performing 64B / 66B encoding on a service stream to obtain a 66-bit code block stream; transcoding the 66-bit code block stream to obtain a transcoded first code block stream, wherein the number of bits of the first code block in the first code block stream is greater than 66; mapping the first code block stream to a first transmission container, and sending the first transmission container, wherein the first transmission container includes an overhead code block and a time slot code block, the number of bits of the overhead code block and the number of bits of the time slot code block are both consistent with the number of bits of the first code block, the overhead code block carries overhead information, and the time slot code block carries the first code block.
[0008] On the other hand, an embodiment of the present application also provides a method for processing a service, including: extracting a first code block stream from the received first target information, wherein the first code block stream is obtained by transcoding a 66-bit code block stream, and the 66-bit code block stream is obtained by 64B / 66B encoding the service stream, and the number of bits of the first code block in the first code block stream is greater than 66; mapping the first code block stream to a second transmission container, and sending the second transmission container, wherein the second transmission container includes an overhead code block and a time slot code block, the number of bits of the overhead code block and the number of bits of the time slot code block are both consistent with the number of bits of the first code block, the overhead code block carries overhead information, and the time slot code block carries the first code block.
[0009] On the other hand, an embodiment of the present application also provides a method for processing a service, including: extracting a third transmission container from the received third target information, and extracting a first code block stream from the third transmission container, wherein the third transmission container includes an overhead code block and a time slot code block, the number of bits of the overhead code block and the number of bits of the time slot code block are both consistent with the number of bits of the first code block in the first code block stream, the overhead code block carries overhead information, the time slot code block carries the first code block, the first code block stream is obtained by transcoding a 66-bit code block stream, the 66-bit code block stream is obtained by performing 64B / 66B encoding on a service stream, and the number of bits of the first code block is greater than 66; reversing the first code block stream to obtain the 66-bit code block stream; and performing 64B / 66B decoding on the 66-bit code block stream to obtain the service stream.
[0010] On the other hand, an embodiment of the present application further provides a network device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the service processing method described above when executing the computer program.
[0011] On the other hand, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the business processing method as described above.
[0012] On the other hand, an embodiment of the present application also provides a computer program product, including a computer program or computer instructions, wherein the computer program or the computer instructions are stored in a computer-readable storage medium, the processor of the network device reads the computer program or the computer instructions from the computer-readable storage medium, and the processor executes the computer program or the computer instructions, so that the network device performs the service processing method as described above. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG1 is a schematic diagram of an optical module architecture using the FlexE protocol in the related art;
[0014] FIG2 is a schematic diagram of the structure of a 66-bit code block in the related art;
[0015] FIG3 is a schematic diagram of the position of a FlexE overhead block in a code block group in the related art;
[0016] FIG4 is a schematic diagram of an example of allocating 66-bit code blocks to transmission paths in the related art;
[0017] FIG5 is a schematic diagram of the structure of a FlexE overhead frame in the related art;
[0018] FIG6 is a schematic diagram of a process of using FlexE frames to carry service information in a related art;
[0019] FIG7 is a schematic diagram of a process of restoring a FlexE frame to service information in the related art;
[0020] FIG8 is a flow chart of data processing specified in the 800 Gbit / s Ethernet interface standard in the related art;
[0021] FIG9 is a schematic diagram of the structure of a 257-bit code block in the related art;
[0022] FIG10 is a schematic diagram of encoding a 257-bit code block when four 66-bit code blocks are all data code blocks in the related art;
[0023] FIG11 is a schematic diagram of encoding of four 66-bit code blocks including three data code blocks and one control code block into a 257-bit code block in the related art;
[0024] FIG12 is a schematic diagram of encoding of four 66-bit code blocks including one control code block and three data code blocks into a 257-bit code block in the related art;
[0025] FIG13 is a schematic diagram of encoding a 257-bit code block when four 66-bit code blocks are all control code blocks in the related art;
[0026] FIG14 is a schematic diagram of an intermediate device processing a 257-bit code block in the related art;
[0027] FIG15 is a flowchart of a method for processing a service provided in an embodiment of the present application;
[0028] FIG16 is a schematic diagram of a new FlexE frame structure based on a 257-bit length according to an embodiment of the present application;
[0029] FIG17 is a schematic diagram of 66B / 257B encoding provided in an embodiment of the present application;
[0030] FIG18 is a schematic diagram of a new FlexE frame structure provided in an embodiment of the present application;
[0031] FIG19 is a schematic diagram of the structure of a new FlexE overhead frame provided in an embodiment of the present application;
[0032] FIG20 is a schematic diagram illustrating the position of a 66-bit overhead code block in a 257-bit code block according to an embodiment of the present application;
[0033] FIG21 is a schematic diagram illustrating the position of a 66-bit overhead code block in a 257-bit code block according to another embodiment of the present application;
[0034] FIG22 is a schematic diagram of the position of a 66-bit overhead code block in a 257-bit code block according to another embodiment of the present application;
[0035] FIG23 is a schematic diagram illustrating the position of a 66-bit overhead code block in a 257-bit code block according to another embodiment of the present application;
[0036] FIG24 is a schematic diagram illustrating the position of a 66-bit overhead code block in a 257-bit code block according to another embodiment of the present application;
[0037] FIG25 is a schematic diagram of the position of a 66-bit overhead code block in a 257-bit code block according to another embodiment of the present application;
[0038] FIG26 is a schematic structural diagram of a FlexE shim layer provided in an embodiment of the present application;
[0039] FIG27 is a flow chart of a method for processing a service executed by a transmitting end device according to an embodiment of the present application;
[0040] FIG28 is a flowchart of a method for processing a service provided by another embodiment of the present application;
[0041] FIG29 is a schematic diagram of an intermediate device according to an embodiment of the present application processing a 257-bit code block;
[0042] FIG30 is a schematic diagram of the structure of a 66-bit idle code block provided in an embodiment of the present application;
[0043] FIG31 is a schematic diagram of encoding four 66-bit idle code blocks into a 257-bit idle code block according to an embodiment of the present application;
[0044] FIG32 is a schematic diagram of inserting a 257-bit idle code block between two 257-bit code blocks according to an embodiment of the present application;
[0045] FIG33 is a schematic diagram of adjusting the position of a 66-bit idle code block in a plurality of 257-bit code blocks according to an embodiment of the present application;
[0046] FIG34 is a flowchart of a method for processing a service provided by another embodiment of the present application;
[0047] Figure 35 is a flowchart of a processing method for a receiving device to execute a service provided in an embodiment of the present application. DETAILED DESCRIPTION
[0048] In order to make the purpose, technical methods and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.
[0049] It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in an order different from that in the flowchart. In the description of the specification, claims and the above-mentioned drawings, the meaning of multiple (or multiple) is more than two, greater than, less than, exceed, etc. are understood to exclude the number itself, and above, below, within, etc. are understood to include the number itself. If there is a description of "first", "second", etc., it is only for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.
[0050] It's worth noting that in current communications networks, network traffic continues to grow rapidly, driving a rapid increase in the bandwidth of communications equipment. Interface bandwidth has increased from 10Mbit / s to 100Mbit / s, 1Gbit / s, and 10Gbit / s, to accommodate this growth. Currently, commercial optical modules for communications equipment have reached 100Gbit / s transmission speeds. However, as speeds exceed 100Gbit / s, technical challenges become increasingly significant, leading to a sharp increase in production costs. While 400Gbit / s optical modules have been developed during the technological evolution from 100Gbit / s to 400Gbit / s, they are prohibitively expensive, exceeding the price of four 100Gbit / s modules. This makes 400Gbit / s modules uneconomical for commercial use. To meet the demand for 400Gbit / s service delivery without increasing costs, the International Standards Organization defined the FlexE protocol, enabling 400Gbit / s traffic to be transmitted over 100Gbit / s optical modules. The FlexE protocol combines multiple 100Gbit / s optical modules to form a logical transmission channel with increased bandwidth. As shown in Figure 1, using the FlexE protocol, four 100Gbit / s optical modules are combined to form a 400Gbit / s transmission channel, equivalent to the service transmission speed of a single 400Gbit / s optical module. This not only meets the 400Gbit / s service delivery demand but also addresses the economic value of service delivery.
[0051] The current physical layer transmission rate defined in the FlexE protocol is 100 Gbit / s. The Ethernet protocol defines that before sending 100 Gbit / s data packets, 64B / 66B encoding is performed on the data packets. This expands the 64-bit data block in the data packet into a 66-bit information block. The additional two bits are placed at the beginning of the 66-bit information block to mark the start of the 66-bit information block. The 66-bit information block is then transmitted from the optical module interface in the form of a 66-bit information block. In the 64B / 66B encoding rules defined in the 802.3 protocol, each code block consists of 66 bits. As shown in Figure 2, the first two bits are the synchronization header of the code block. When the synchronization header bits are "01", it indicates a D code block (i.e., a data code block), and the following 8 bytes (64 bits) are 8 bytes of data content. When the synchronization header bits are "10", it indicates a control code block. The first byte that follows is the block type field, which indicates the specific type of the control code block. The following 7 bytes are the content of the control code block. The content of these 7 bytes is associated with the specific type of the control code block. For a control code block, the block type field is 8 bits long and contains specific coded content. Different block type field contents represent different types of control code blocks. The block type field can be divided into an f field and an s field, both of which consist of 4 bits. The contents of the f field and the s field are one-to-one corresponding, and the contents of the f field and the s field can be the same value or opposite values. For example, the control field of an idle code block contains 0x1E (in general technical terms, 0x is a hexadecimal designation, indicating that the following data is in hexadecimal format; the same applies below). The f field contains 0x1, and the s field contains 0xE. The f and s fields are bitwise inverted. For a T1 code block, the control field contains 0x99, where the f field contains 0x9, and the s field also contains 0x9. The f and s fields are bitwise identical. Therefore, the f and s fields have a one-to-one correspondence. Once the content of one field is determined, the content of the other can be determined using the encoding rules shown in Figure 2. Among these, the S code block (start code block), T code block (end code block), O code block, and ilde code block all belong to control code blocks. The block type field in an S code block contains 0x78, indicating that this control code block is an S code block. In addition to indicating the end code block, the T code block can also carry service byte content (located in the last 7 bytes of the code block).The Ethernet standard defines eight types of T-blocks: T0, T1, T2, T3, T4, T5, T6, and T7. T0 (the first byte of the block type field is 0x87) carries no service information, T1 (the first byte is 0x99) carries one byte of service information, T2 (the first byte is 0xAA) carries two bytes of service information, and so on. It should be noted that in 66-bit and 257-bit encodings, all fields are stored and transmitted in reverse order within the block. However, for ease of reading, international standards and technical documents directly present the meaning of each field within the block. While this differs from the order in which the field is transmitted within the block, the meaning is the same.
[0052] In each 100 Gbit / s physical component (i.e., optical module) defined by the current FlexE protocol, every 20 66-bit information blocks can be divided into a code block group. Each code block group contains a total of 20 information blocks, representing 20 time slots (i.e., each information block corresponds to a time slot), and each time slot represents a service speed of 5 Gbit / s bandwidth. When transmitting 66-bit information blocks, a FlexE overhead block can be inserted after every 1023 code block groups (1023 * 20 information blocks) are sent, as shown in black in Figure 3. After inserting this overhead block, the code block group is sent again. After the second 1023 code block groups (1023 * 20 information blocks) are sent, another overhead block is inserted, and so on. In this way, overhead blocks are periodically inserted during the transmission of information blocks, with the interval between two adjacent overhead blocks being 1023 * 20 information blocks. If the transmission speed of the physical line is 100 Gbit / s, the FlexE protocol divides the physical port into 20 time slots, so the bandwidth corresponding to each time slot is 5 Gbit / s.
[0053] When four 100 Gbit / s physical layer channels form a 400 Gbit / s logical service bandwidth, as shown in Figure 4, each physical layer channel still organizes information blocks of 20 time slots into a code block group, with an overhead block inserted every 1023 code block groups. In the FlexE master calendar (located in the shim layer), the four 20-time slot information blocks are assembled into an information block group consisting of 80 time slots. This information block group includes 80 time slots. Service information is transmitted in these 80 time slots, and the bandwidth of each time slot is 5 Gbit / s. Therefore, the shim layer provides a total of 400 Gbit / s of service transmission bandwidth.
[0054] The FlexE overhead block is a 66-bit block. When transmitting a service flow, one overhead block is inserted every 1023 x 20 information blocks. The overhead block serves as a location within the service flow. Determining the location of the overhead block can determine the position of the first information block group and subsequent information block groups within the service flow. Figure 5 shows the contents of an overhead block. Eight consecutive overhead blocks form a FlexE overhead frame. An overhead block consists of a 2-bit block synchronization header and 64-bit block content. The block synchronization header is located in the first two columns, and the following 64 columns contain the block content. The first overhead block has a block flag of 10, while the following seven overhead blocks have a block flag of 01 or SS (SS indicates unspecified content). The current FlexE protocol defines an overhead frame consisting of eight overhead blocks. This means that an overhead frame contains eight overhead blocks. The first overhead block is identified by its two fields: 0x4B (hexadecimal notation) and 0x05 (hexadecimal notation). If the corresponding contents of 0x4B and 0x05 are detected in an overhead block, it indicates that this overhead block is the first overhead block. This first overhead block and the following seven overhead blocks form an overhead frame. The contents of the first overhead block include: 0x4B (8 bits, hexadecimal 0x4B), C bit (1 bit, indicating justification control), OMF bit (1 bit, indicating overhead frame multiframe indicator), RPF bit (1 bit, indicating remote defect indication), RES bit (1 bit, reserved bit), FlexE group number (20 bits, indicating the bundling group number), 0x5 (4 bits, hexadecimal 5), and 000000 (28 bits, all 0s). 0x4B and 0x5 are flags indicating the first overhead block. When receiving a service stream, if the corresponding contents of an overhead block are 0x4B and 0x5, it indicates that this overhead block is the first overhead block in an overhead frame. This overhead block and the following seven consecutive overhead blocks form an overhead frame. In the overhead frame, the reserved portion is reserved and undefined in the current FlexE protocol. The PHY number indicates the physical layer member's number within the group, ranging from 0 to 255. The PHY map indicates the presence of each physical layer member within the group. The PHY map in an overhead frame consists of 8 bits, and 256 bits in 32 multiframes. These bits indicate whether each of the 256 physical layer members is in the group. If so, the corresponding position is set to "1"; otherwise, it is set to "0." A 100 Gbit / s FlexE frame has 20 timeslots, each of which can carry service information. The client calendar indicates the service name carried in each timeslot, represented by client calendar A and client calendar B.During normal operation, only one of Client calendar A and Client calendar B is used to indicate that it is in working state (the C bit indicates which group is in working state), and the other group is in standby state.
[0055] Refer to Figure 6, which illustrates the process of using FlexE frames to carry services. During this process, the service stream is first 64B / 66B encoded. Specifically, the service stream is cut into 64-bit (8-byte) data blocks. These 64-bit blocks are then 64B / 66B encoded to produce 66-bit information blocks. This 64B / 66B encoding transforms the service stream into a 66-bit information block stream. Idle blocks are then inserted or deleted from the information block stream, and the speed of the information block stream is adjusted to match the rate of the FlexE protocol master calendar. The 66-bit information blocks are then placed into the FlexE protocol master calendar based on the timeslot configuration. In the FlexE protocol, each physical layer member is allocated 20 timeslots (each timeslot corresponds to a 66-bit information block, representing 5 Gbit / s of service bandwidth). If there are four physical layer members, the master calendar has a total of 80 timeslots. Relevant configuration information determines which timeslots are selected to carry each service's information block stream. The master calendar then groups all time slots into groups of 20, assigning them to each physical layer member defined by the FlexE protocol. Each physical layer member then inserts FlexE overhead blocks into these time slots (overhead blocks are also 66 bits long, with one inserted every 20*1023 time slots). In Figure 6, each physical layer member can be considered a sub-calendar, carrying the information block stream. After inserting the FlexE overhead blocks, each physical layer member scrambles the carried information block stream and then transmits the scrambled information block stream through the payload mapping agent (PMA). At the receiving end, as shown in Figure 7, after the PMA receives the information block stream, it first descrambles it to restore it into multiple 66-bit information blocks. Within these 66-bit information blocks, each physical layer member searches for the FlexE overhead blocks and, using the overhead blocks as a reference, restores the FlexE frame structure to obtain a sub-calendar. The time slots of all physical layer members are then sorted in order to restore the master calendar structure. Then, according to the relevant configuration information, the information blocks are taken from the corresponding time slots in the master calendar, and the idle information blocks are deleted. Then, 66B / 64B decoding is performed to restore the original service flow.
[0056] As physical interface transmission speeds increase, Ethernet physical interfaces need to re-encode 66-bit code blocks to reliably transmit information bits. For example, four 66-bit code blocks can be encoded into one 257-bit code block, which is then transmitted as a 257-bit code block. Converting four 66-bit code blocks into one 257-bit code block saves seven bits. With these saved bits, bits representing the FEC function can be inserted, allowing error correction and verification of the transmitted service code blocks while maintaining the total number of bits, thereby improving the transmission quality of the code blocks. Figure 8 shows the data processing flow specified by the 800 Gbit / s Ethernet interface standard. In this data processing flow, 66-bit code blocks are divided into two groups. The 66-bit code blocks in each group are 66B / 257B encoded. After processing by various modules, such as the scramble module, aligment insert module, and FEC module, they are transmitted and output. All of this processing is performed on 257-bit code blocks. As shown in Figure 8, the PCS layer primarily processes code blocks with a length of 257 bits. The structure of a 257-bit code block is shown in Figure 9. The total length of a 257-bit code block is 257 bits (from 0 to 256). The first bit is the synchronization header. A synchronization header of 1 indicates that the 257-bit code block is a data code block. This code block consists of a synchronization header and four content fields. The 256 bits following the synchronization header correspond to four content fields (D1 to D4). Each content field contains the last 8 bytes (64 bits) of the 66-bit code block. A synchronization header of 0 indicates that the 257-bit code block is a code block with a control block. This code block consists of a synchronization header, a 4-bit type field, and four content fields (D1 to D4). The 4-bit type field (bits 1 to 4) following the synchronization header contains a type value, indicating the content type of the following four content fields. Each bit corresponds to the content type of a content field. For example, when the type bit value of the type field is 1, it indicates that the content type of the corresponding content field is a data code block type; when the type bit value of the type field is 0, it indicates that the content type of the corresponding content field is a control code block type. The last 252 bits of the 257-bit code block correspond to four content fields, three of which are 64 bits long, and the remaining content field is 60 bits long (the first control code block type has a content length of 60). In the example of Figure 9, assuming the type field is 10xx, this indicates that the first content field is a data code block type, the second content field is a control code block type, and the third and fourth content fields are code blocks of any type. Therefore, the length of the first content field is 64 bits, the length of the second content field is 60 bits, and the length of the third and fourth content fields are both 64 bits.
[0057] The 66B / 257B encoding rule specified in the Ethernet standard, which encodes four 66-bit code blocks into one 257-bit code block, is as follows:
[0058] 1. When all four 66-bit blocks are data blocks, the encoded 257-bit block consists of two parts: a 1-bit synchronization header and a 256-bit payload. The synchronization header consists of a single bit, "1," indicating that the following four data fields are present. The payload consists of four data fields, each containing 8 bytes of data.
[0059] 2. When the four 66-bit code blocks include data code blocks and control code blocks, or all are control code blocks, the encoded 257-bit code block consists of three parts: a synchronization header, a type area, and a payload area. Among them, the synchronization header has only one bit with a value of "0". Immediately following is the type area, which consists of 4 bits. Each bit indicates the content type of each of the 4 data fields in the following payload area. When a bit in the type area is 1, it indicates that the content of the corresponding data field is the content of the 66-bit code block. When a bit in the type area is 0, it indicates that the content of the corresponding data field is the content of the control code block. The payload area at the last position is 4 data fields. The content of these 4 data fields is the content of 4 66-bit code blocks. The first control type code block in the 4 66-bit code blocks only retains half of the content of the block type field of the original control type code block (for example, the content of the 4-bit f field described above) and the following 7 bytes. The other data code blocks in the 4 66-bit code blocks and all control code blocks after the first control type code block all store the content of 8 bytes in the code block.
[0060] Figure 10 shows the encoding rules for encoding four 66-bit code blocks into 257-bit code blocks when all four 66-bit code blocks are data code blocks. In Figure 10, the synchronization header in the 66-bit data code block is "01," and the synchronization header of the encoded 257-bit code block is "1." The synchronization header of the 257-bit code block is followed by the 8-byte content of each of the four 66-bit data code blocks. Figure 11 shows the encoding rules for encoding four 66-bit code blocks into 257-bit code blocks when they include three data code blocks and one control code block. In Figure 11, the synchronization header of the 257-bit code block is "0," and the content of the control field is "1110," indicating that it consists of three 66-bit data code blocks and one 66-bit control code block. The content following the control field is the byte contents of three 66-bit data code blocks and the contents of one 66-bit control code block. Only 60 bits of the 66-bit control code block are retained, namely, half of the block type field in the original code block of the 66-bit control code block (for example, the contents of the 4-bit f field described above) and the following 7 bytes. Figure 12 shows the encoding rules for encoding four 66-bit code blocks, including one control code block and three data code blocks, into a 257-bit code block. In Figure 12, the synchronization header of the 257-bit code block is "0" and the contents of the control field are "0111", indicating that it consists of one 66-bit control code block and three 66-bit data code blocks. Only 60 bits of the 66-bit control code block are retained, namely, half of the block type field in the original code block of the 66-bit control code block (for example, the contents of the 4-bit f field described above) and the following 7 bytes. The contents of this 66-bit control code block are followed by the byte contents of three 66-bit data code blocks. Figure 13 shows the encoding rules for encoding four 66-bit code blocks, including four control code blocks, into 257-bit code blocks. In Figure 13, the synchronization header of the 257-bit code block is "0", the content of the control field is "0000", and the control field is followed by half of the block type field in the original code block of the first 66-bit control code block (for example, the content of the 4-bit f field described above) and the following 7 bytes, followed by the 8 bytes of the remaining three 66-bit control code blocks.
[0061] In current application scenarios, the optical module interface processes signals in 257-bit block format at the physical layer, while the FlexE layer processes signals in 66-bit block format. Therefore, the optical module must process both block formats. After receiving a service flow at the device's receive port, it first locates the 257-bit block within the service flow and then converts each 257-bit block into four 66-bit blocks, as shown in Figure 14. FlexE frames are then framed within the 66-bit blocks. Each timeslot in the FlexE protocol is then identified, and the 66-bit blocks for each service flow are determined based on the information carried in each timeslot. For each service flow, the service block stream is cross-processed in 66-bit blocks and then sent to the corresponding transmit port. Internally, the service flow rate received by the receive port is determined by the upstream device, while the rate of the transmit port is determined by the device itself. Therefore, the processing speed of the receive port and the transmit port may differ. On the sending port, the speed of the service code block flow is adjusted by adding and deleting idle code blocks in the service flow to adapt to the speed of the FlexE frame in the sending direction. The speed-adjusted service flow is mapped into the FlexE frame of the sending port. Finally, the 66-bit code block of the FlexE frame is converted into a 257-bit code block and sent out on the sending port.
[0062] In the current FlexE standard, each time slot corresponds to a 66-bit code block, representing a 5Gbit / s transmission rate. However, data processing on high-speed Ethernet interfaces such as 800Gbit / s is based on 257-bit lengths. If the FlexE protocol continues to process data at 800Gbit / s using the 66-bit length per time slot and 5Gbit / s per time slot, the number of time slots processed will be very large, reducing data processing efficiency. Furthermore, for intermediate devices, internal conversion from 257-bit code blocks to 66-bit code blocks and then back to 257-bit code blocks will be required, requiring two code block encoding format conversions, which will increase processing circuit costs.
[0063] In order to increase the transmission bandwidth of a single time slot, reduce the number of processed time slots, and thus improve the efficiency of data processing, an embodiment of the present application provides a service processing method, a network device, a computer-readable storage medium, and a computer program product, wherein, after the service stream is 64B / 66B encoded to obtain a 66-bit code block stream, the 66-bit code block stream is first transcoded to obtain a first code block stream with a larger number of bits, and then the first code block stream with a larger number of bits is mapped to a first transmission container, and the first transmission container is sent. Since the first transmission container includes overhead code blocks and time slot code blocks, wherein the number of bits of the overhead code blocks and the number of bits of the time slot code blocks are both consistent with the number of bits of the first code block in the first code block stream, and the overhead code blocks carry overhead information and the time slot code blocks carry the first code blocks, more service information can be carried in the time slot code blocks, thereby increasing the transmission bandwidth of a single time slot, reducing the number of processed time slots, and thus improving the efficiency of data processing.
[0064] Based on the above analysis, the embodiments of the present application will be further described below in conjunction with the accompanying drawings.
[0065] Referring to Figure 15, Figure 15 is a flowchart of a service processing method provided by an embodiment of the present application. The service processing method can be executed by a sending end device, and the service processing method may include but is not limited to steps S1510 to S1530.
[0066] Step S1510: Perform 64B / 66B encoding on the service stream to obtain a 66-bit code block stream.
[0067] Step S1520: transcode the 66-bit code block stream to obtain a transcoded first code block stream, wherein the number of bits of the first code block in the first code block stream is greater than 66.
[0068] Step S1530: Map the first code block stream to a first transmission container and send the first transmission container, where the first transmission container includes an overhead code block and a time slot code block. The number of bits in the overhead code block and the number of bits in the time slot code block are both consistent with the number of bits in the first code block. The overhead code block carries overhead information, and the time slot code block carries the first code block.
[0069] In a feasible implementation, the service flow can be ordinary Ethernet service information or high service quality service information. For example, the high service quality service information can be CBR service, high service quality Ethernet service information (such as eCPRI (ethernet Common Public Radio Interface) service information), voice service information, video service information, game service information, etc., which are not specifically limited here. The high service quality service information can be encapsulated in various formats, such as eCPRI protocol message format or Ethernet message format, etc.; ordinary Ethernet service information can be download service information, etc., which are not specifically limited here.
[0070] In a feasible implementation, the transcoding performed on the 66-bit code block stream may be 66B / 257B encoding, so that the first code block obtained after transcoding may be a code block with a length of 257 bits.
[0071] In one possible implementation, a time slot code block is a code block transmitted in one time slot.
[0072] In a feasible implementation, the overhead code block may include a first overhead code block and a second overhead code block, and a fixed number of time slot code blocks are spaced between the overhead code blocks in the first transmission container, for example, 4*1023*5 time slot code blocks are spaced between the overhead code blocks in the first transmission container. In addition, the first transmission container may be arranged in the order of a first overhead code block, multiple time slot code blocks, a second overhead code block, and multiple time slot code blocks. The first overhead code block may carry the overhead content of the first four overhead blocks in the FlexE overhead frame, and the second overhead code block may carry the overhead content of the last four overhead blocks in the FlexE overhead frame. In one embodiment, the first overhead code block, the time slot code block, and the second overhead code block may all be code blocks with a length of 257 bits. Therefore, the first transmission container arranged in the order of a first overhead code block, multiple time slot code blocks, a second overhead code block, and multiple time slot code blocks can form a new FlexE frame based on a 257-bit length provided in an embodiment of the present application.
[0073] In a feasible implementation, the first overhead code block may include a first synchronization header, a first code block type field, a first overhead field, a second overhead field, a third overhead field, and a fourth overhead field. The content of the first code block type field may be used to indicate the content type of the first overhead field, the second overhead field, the third overhead field, and the fourth overhead field. The first overhead field may carry the overhead content of the first overhead block in the FlexE overhead frame, the second overhead field may carry the overhead content of the second overhead block in the FlexE overhead frame, the third overhead field may carry the overhead content of the third overhead block in the FlexE overhead frame, and the fourth overhead field may carry the overhead content of the fourth overhead block in the FlexE overhead frame. The first overhead field may include a first overhead field and a second overhead field. The first overhead field may carry part of the first byte of the first overhead block in the FlexE overhead frame, and the second overhead field may carry the last seven bytes of the first overhead block in the FlexE overhead frame.
[0074] In a feasible implementation manner, when the last four overhead blocks in the FlexE overhead frame are all data blocks, the second overhead code block may include a second synchronization header, a fifth overhead field, a sixth overhead field, a seventh overhead field and an eighth overhead field, wherein the fifth overhead field can carry the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field can carry the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field can carry the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field can carry the overhead content of the eighth overhead block in the FlexE overhead frame.
[0075] In a feasible implementation manner, when there is a control block in the last four overhead blocks in the FlexE overhead frame, the second overhead code block may include a second synchronization header, a second code block type field, a fifth overhead field, a sixth overhead field, a seventh overhead field and an eighth overhead field, wherein the content of the second code block type field can be used to indicate the content type of the fifth overhead field, the sixth overhead field, the seventh overhead field and the eighth overhead field, the fifth overhead field can carry the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field can carry the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field can carry the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field can carry the overhead content of the eighth overhead block in the FlexE overhead frame.
[0076] In a feasible embodiment, when the first overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the fifth overhead block in the FlexE overhead frame is a control block, the fifth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the fifth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the fifth overhead block in the FlexE overhead frame.
[0077] In a feasible embodiment, when the second overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the sixth overhead block in the FlexE overhead frame is a control block, the sixth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the sixth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the sixth overhead block in the FlexE overhead frame.
[0078] In a feasible implementation, when the third overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the seventh overhead block in the FlexE overhead frame is a control block, the seventh overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the seventh overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the seventh overhead block in the FlexE overhead frame.
[0079] In a feasible implementation, when the fourth overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the eighth overhead block in the FlexE overhead frame is a control block, the eighth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the eighth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the eighth overhead block in the FlexE overhead frame.
[0080] In this embodiment, by adopting the service processing method including the above-mentioned steps S1510 to S1530, after 64B / 66B encoding is performed on the service stream to obtain a 66-bit code block stream, the 66-bit code block stream is transcoded to obtain a first code block stream with a larger number of bits, and then the first code block stream with a larger number of bits is mapped to a first transmission container, and the first transmission container is sent. Since the first transmission container includes overhead code blocks and time slot code blocks, wherein the number of bits of the overhead code blocks and the number of bits of the time slot code blocks are both consistent with the number of bits of the first code blocks in the first code block stream, and the overhead code blocks carry overhead information and the time slot code blocks carry the first code blocks, more service information can be carried in the time slot code blocks, thereby increasing the transmission bandwidth of a single time slot, reducing the number of processed time slots, and thus improving data processing efficiency.
[0081] In one embodiment, during the process of transcoding a 66-bit code block stream to obtain a transcoded first code block stream, 66-bit idle code blocks may be first inserted or deleted from the 66-bit code block stream to obtain a rate-adapted 66-bit code block stream, and then the rate-adapted 66-bit code block stream may be transcoded to obtain a transcoded first code block stream. By inserting or deleting 66-bit idle code blocks from the 66-bit code block stream, the rate of the 66-bit code block stream can be adjusted, thereby achieving rate adaptation between service flows and bearer timeslots, thereby improving the transmission efficiency of service flows.
[0082] In one embodiment, during transcoding of a speed-adapted 66-bit code block stream to obtain a transcoded first code block stream, multiple 66-bit idle code blocks in the speed-adapted 66-bit code block stream may be first positionally adjusted to obtain a 66-bit code block stream in which the multiple 66-bit idle code blocks are aggregated. The 66-bit code block stream in which the multiple 66-bit idle code blocks are aggregated is then transcoded to obtain the transcoded first code block stream. By positionally adjusting the multiple 66-bit idle code blocks to aggregate the multiple 66-bit idle code blocks, the multiple 66-bit idle code blocks can be grouped together. This facilitates converting the 66-bit idle code blocks into target idle code blocks (e.g., 257-bit idle code blocks) having the same number of bits as the first code block during subsequent transcoding steps, thereby facilitating deletion of the generated target idle code blocks to achieve speed adjustment of the first code block stream.
[0083] In one embodiment, during the transcoding of a 66-bit code block stream, a 66-bit idle code block may be first inserted or deleted in the 66-bit code block stream to obtain an idle code block group consisting of four consecutive 66-bit idle code blocks, and then the idle code block group may be transcoded to obtain a target idle code block, wherein the number of bits of the target idle code block is consistent with the number of bits of the first code block.
[0084] In one embodiment, during transcoding of a 66-bit code block stream, when a preset specific situation exists among four consecutive 66-bit code blocks used for the same transcoding, a 66-bit idle code block may be inserted or deleted between an end code block and a start code block, such that the end code block is located within the four consecutive 66-bit code blocks of the previous transcoding, and the start code block is located within the four consecutive 66-bit code blocks of the next transcoding. The preset specific situation includes one of the following:
[0085] Among four consecutive 66-bit code blocks, the first 66-bit code block is the end code block, the second 66-bit code block is the start code block, and the third 66-bit code block and the fourth 66-bit code block are code blocks of any type; among four consecutive 66-bit code blocks, the first 66-bit code block is the end code block, the second 66-bit code block and the fourth 66-bit code block are code blocks of any type, and the third 66-bit code block is the end code block; among four consecutive 66-bit code blocks, the first 66-bit code block is the end code block, the second 66-bit code block and the third 66-bit code block are code blocks of any type, and the fourth 66-bit block is the start code block; In four consecutive 66-bit code blocks, the first 66-bit code block and the fourth 66-bit code block are both code blocks of any type, the second 66-bit code block is the end code block, and the third 66-bit code block is the start code block; in four consecutive 66-bit code blocks, the first 66-bit code block and the third 66-bit code block are both code blocks of any type, the second 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block; in four consecutive 66-bit code blocks, the first 66-bit code block and the second 66-bit code block are both code blocks of any type, the third 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block.
[0086] In one embodiment, when mapping the first code block stream to the first transmission container, target idle code blocks may be inserted or deleted from the first code block stream to obtain a rate-adapted first code block stream, wherein the number of bits of the target idle code blocks is consistent with the number of bits of the first code blocks. The rate-adapted first code block stream is then mapped to the first transmission container. Inserting or deleting target idle code blocks from the first code block stream adjusts the speed of the first code block stream, thereby achieving speed adaptation between the service flow and the bearer timeslot, thereby improving the transmission efficiency of the service flow.
[0087] In one embodiment, when mapping the first code block stream to the first transmission container, the first code block stream may be first mapped to multiple time slot code blocks, the multiple time slot code blocks are then assigned to different transmission instances, and the first overhead code block and the second overhead code block are inserted at a preset position in each transmission instance, thereby obtaining a first transmission container carried by the multiple transmission instances, wherein a preset number of time slot code blocks exists between the first overhead code block and the second overhead code block. In one embodiment, the preset number may be 4*1023*5, that is, there are 4*1023*5 time slot code blocks between the first overhead code block and the second overhead code block.
[0088] In one embodiment, after obtaining first transmission containers carried by multiple transmission instances, the first transmission containers carried by the multiple transmission instances may be subjected to code block interleaving to obtain first target information including the first transmission container, and then the first target information may be sent. In the process of performing code block interleaving on the first transmission containers carried by the multiple transmission instances to obtain the first target information including the first transmission container, a padding code block may be first inserted into the first transmission container carried by each transmission instance to obtain a first candidate transmission container carried by each transmission instance, wherein the number of bits in the padding code block is consistent with the number of bits in the first code block. Subsequently, code block interleaving may be performed on the first candidate transmission containers carried by the multiple transmission instances to obtain the first target information including the first transmission container.
[0089] It should be noted that, in one embodiment, when the rate of the Ethernet physical interface is 50Gbit / s, 200Gbit / s, 400Gbit / s, 800Gbit / s or 1600Gbit / s, it is necessary to insert a padding code block into the first transmission container carried by each transmission instance. In this case, after the subsequent receiving end device or intermediate device receives the first target information and performs code block deinterleaving on the first target information, it is necessary to delete the padding code block accordingly. In another embodiment, when the rate of the Ethernet physical interface is 100Gbit / s, it is not necessary to insert a padding code block into the first transmission container carried by each transmission instance. Therefore, in this case, after the subsequent receiving end device or intermediate device receives the first target information and performs code block deinterleaving on the first target information, it is not necessary to delete the padding code block accordingly.
[0090] The following describes in detail the method for processing the services provided in the embodiments of the present application using specific examples.
[0091] For example, as shown in Figure 16, Figure 16 is a schematic diagram of a new FlexE frame structure based on a 257-bit length provided by an embodiment of the present application. In the FlexE frame structure of the current related art, the length of the code block is 66 bits, and the distribution of the overhead blocks is that one overhead block is set every 1023*20 code blocks. In the new FlexE frame structure provided by the embodiment of the present application, four consecutive overhead blocks are set every 4*1023*20 code blocks. In Figure 16, these four consecutive overhead blocks are the first four overhead code blocks or the last four overhead code blocks in the FlexE frame structure of the current related art. Starting from the fourth overhead block, 66B / 257B encoding is performed on each of the four code blocks, which can be converted into a 257-bit code block. The conversion process can be shown in Figure 17. In the new FlexE frame structure, it is composed of 257-bit code blocks, where a 257-bit overhead block is set every 20*1023 257-bit code blocks. As shown in Figure 18, in the new FlexE frame structure, the basic code block length is a 257-bit code block. Both the service code block and the overhead code block are 257-bit code blocks. Each 257-bit code block corresponds to a time slot, so each time slot can represent a data rate of 20 Gbit / s. Each physical interface member has a total of five time slots. A 257-bit overhead code block is inserted between every 4*1023*5 257-bit code blocks. Two consecutive 257-bit overhead code blocks constitute the content of the FlexE frame. As shown in Figure 19, the first 257-bit code block carries the contents of blocks 1, 2, 3, and 4 of the 66-bit overhead block in the FlexE overhead frame, while the second 257-bit code block carries the contents of blocks 5, 6, 7, and 8 of the 66-bit overhead block in the FlexE overhead frame. Of the eight overhead blocks in a FlexE overhead frame, the first is a control block, the second and third are data blocks, and the fourth, fifth, sixth, seventh, and eighth overhead blocks are of undefined type, potentially either data or control blocks. For a new FlexE overhead frame consisting of two 257-bit blocks, the four 66-bit overhead blocks in the first 257-bit block consist of one control block, two data blocks, and one data or control block.Because the first 66-bit code block is fixed as a control code block (characteristic values in the 66-bit code block include the block synchronization header bit "10", the block type field value "0x4B", and the sequence value "0x5"), the four 66-bit overhead code blocks in the 257-bit code block are stored in fixed positions within the 257-bit code block. The specific positions are shown in Figure 20. Block 1 of the 66-bit overhead block is located from bits 5 to 64 of the 257-bit code block (the block control field only retains half of the 8 bits, that is, the 0x4B field retains the 0xB content). Block 2 is located from bits 65 to 128 of the 257-bit code block, Block 3 is located from bits 129 to 192 of the 257-bit code block, and Block 4 is located from bits 193 to 256 of the 257-bit code block. The four 66-bit overhead blocks in the subsequent 257-bit code block include Block 5, Block 6, Block 7, and Block 8. Since any of the four 66-bit overhead blocks, block5, block6, block7, and block8, may be a data code block or a control code block, the position of these four 66-bit code blocks in the 257-bit code block needs to be determined according to the type of each 66-bit code block. When block 5, block 6, block 7, and block 8 are all data code blocks, the positions of these four 66-bit overhead blocks in the 257-bit code block are shown in FIG21 ; when block 5 is a control code block (block 6, block 7, and block 8 are all code blocks of any type), the positions of these four 66-bit code blocks in the 257-bit code block are shown in FIG22 ; when block 5 is a data code block and block 6 is a control code block (block 7 and block 8 are all code blocks of any type), the positions of these four 66-bit code blocks in the 257-bit code block are shown in FIG23 ; when block 5 and block 6 are all data code blocks and block 7 is a control code block (block 8 is all code block of any type), the positions of these four 66-bit code blocks in the 257-bit code block are shown in FIG24 ; when block 5, block 6, and block 7 are all data code blocks and block 8 is a control code block, the positions of these four 66-bit code blocks in the 257-bit code block are shown in FIG25 . For the combinations of different code block types in the four 66-bit overhead blocks (i.e., block 5, block 6, block 7, and block 8) in the FlexE overhead frame, after 66B / 257B encoding is performed on these four 66-bit overhead blocks, each 66-bit code block will be in a fixed position within the 257-bit code block.In addition, for the inverse process of 66B / 257B encoding (that is, the process of 66B / 257B decoding, or the process of reversing the code), if a 257-bit overhead block is obtained, then the position of the four 66-bit overhead blocks in the FlexE overhead frame within the 257-bit code block can be determined based on the synchronization header bit value and the control type bit value in the 257-bit code block. This can also determine the position of the overhead content defined by the FlexE protocol in Figure 6 in the frame composed of two 257-bit overhead blocks in Figure 20.
[0092] In addition, according to the new FlexE frame structure based on 257 bits shown in Figure 18, the length of the time slot code block and the overhead code block in the FlexE protocol are both 257-bit code block structures. Each physical interface member has 5 time slots, each time slot corresponds to a 257-bit code block, and each time slot represents a transmission bandwidth of 20 Gbit / s. A 257-bit overhead code block is transmitted every 4*1023*5 time slots. Every two 257-bit overhead code blocks constitute a new FlexE overhead frame. Each new FlexE overhead frame carries the contents of 8 66-bit overhead blocks (block 1 to block 8) in the FlexE overhead frame in the current related art. These blocks 1 to block 8 carry all the overhead content in this new FlexE overhead frame, such as C bit, OMF bit, RPF bit, FlexE group number, PHY number, PHY map, etc.
[0093] As shown in Figure 26, Figure 26 is a structural diagram of a FlexE shim layer (master calendar) provided in an embodiment of the present application. According to Figure 26, it can be seen that the FlexE master calendar consists of n*5 time slots (n is an arbitrary positive integer), and each time slot corresponds to a 257-bit code block, representing a transmission speed of 20Gbit / s. According to the bandwidth requirements of the service flow, any number of time slots can be selected to carry the service flow. When carrying the service flow, the service flow is first 66B / 257B encoded, and the service flow is converted into a 257-bit code block stream, and then mapped to the corresponding FlexE shim layer time slot. Among them, the n*5 time slot code blocks of the FlexE shim layer are shared by n transmission instances, and each transmission instance shares 5 time slots. In each transmission instance, a 257-bit FlexE overhead block is inserted every 4*1023*5 257-bit code blocks, and every two 257-bit FlexE overhead blocks constitute a new FlexE overhead frame. The new FlexE overhead frame includes eight 66-bit overhead blocks defined by the FlexE protocol in the current related art, and these overhead blocks contain FlexE overhead content.
[0094] As shown in Figure 27, Figure 27 is a flow chart of a method for processing services executed by a transmitting device according to an embodiment of the present application. In Figure 27, each service's Ethernet message is first 64B / 66B encoded into a 66-bit code block, then further 66B / 257B encoded into a 257-bit code block. The 257-bit code block is then mapped to the corresponding time slot on the master calendar based on the service's selected bearer time slot. To achieve speed adaptation between service information and bearer time slots, the service code block (e.g., a 66-bit code block or a 257-bit first code block) can be speed-adapted by inserting or deleting some idle code blocks ("I blocks") in the service code block stream, adjusting the speed of the service code block to the speed of the corresponding time slot. The service code block is then mapped to the corresponding time slot on the master calendar for carrying. There are two ways to add and delete idle code blocks. Method 1 uses 66-bit code blocks as processing units for addition or deletion. Method 1 can be performed between the module performing 64B / 66B encoding and the module performing 66B / 257B encoding, as shown by the dashed "idle add / delete" module in the upper row of Figure 27. Method 2 uses 257-bit code blocks as processing units for addition or deletion. Method 2 can be performed between the module performing 66B / 257B encoding and the master calendar module, as shown by the dashed "idle add / delete" module in the lower row of Figure 27. Both methods 1 and 2 can meet the requirements, and either method can be selected during implementation. It should be noted that when using method 2, since idle code blocks can only be inserted between two messages and not within a single message, the last 66-bit code block in the previous 257-bit code block must be a control code block, and the first 66-bit code block in the next 257-bit code block must also be a control code block. Only when the two 257-bit code blocks meet this condition can a 257-bit idle code block (i.e., the target idle code block described above, obtained by encoding four 66-bit idle code blocks) be inserted between the two 257-bit code blocks. To meet the above conditions, four 66-bit code blocks that meet the requirements can be selected during 66B / 257B encoding. Among the four selected 66-bit code blocks, the S code block, D code block, and T code block must belong to only one message and cannot be composed of 66-bit code blocks from two messages, that is, they cannot be composed of the T code block at the end of the previous message and the S code block at the beginning of the next message. Therefore, when performing 66B / 257B encoding, you may encounter a scenario where a group of four 66-bit code blocks is in one of the following formats and cannot be encoded:
[0095] Format 1: T code block + S code block + any type of code block + any type of code block.
[0096] Format 2: T code block + any type of code block + S code block + any type of code block.
[0097] Format 3: T code block + any type code block + any type code block + S code block.
[0098] Format 4: any type of code block + T code block + S code block + any type of code block.
[0099] Format 5: Any type of code block + T code block + any type of code block + S code block.
[0100] Format 6: Any type of code block + any type of code block + T code block + S code block.
[0101] When performing 66B / 257B encoding and encountering a group of four 66-bit code blocks that meets one of the six formats described above, adjustments need to be made to the group of four 66-bit code blocks being encoded. For example, one or more 66-bit idle code blocks can be inserted or deleted between the T block and the S block, and the T and S blocks can be divided into two groups of four 66-bit code blocks, so that the first group of four 66-bit code blocks contains only T blocks and no S blocks, and the second group of four 66-bit code blocks contains only S blocks and no T blocks. This encoding adjustment ensures that the two preceding and succeeding 257-bit code blocks meet the requirement for inserting a 257-bit idle code block, making it easier to insert a 257-bit idle code block during data processing. Of course, during the above adjustments, when inserting or deleting one or more 66-bit idle code blocks, all four 66-bit code blocks in a group can be idle code blocks, which facilitates the subsequent deletion of 257-bit idle code blocks. Therefore, when performing 66B / 257B encoding, some 66-bit idle code blocks can be inserted or deleted, so that the four 66-bit code blocks for 66B / 257B encoding are all 66-bit idle code blocks. These four 66-bit idle code blocks can then be 66B / 257B encoded to obtain a 257-bit idle code block, making it possible to subsequently delete the 257-bit idle code blocks.
[0102] Furthermore, after the 257-bit code block (i.e., the first code block) of a service is mapped to a master calendar consisting of 257-bit code blocks, the n*5 time slots in the master calendar can be divided into n transmission instances, each carrying five time slots. Each transmission instance can insert a 257-bit overhead code block while carrying the 257-bit code block of five time slots. A 257-bit overhead code block is inserted every 4*5*1023 257-bit code blocks, and two 257-bit overhead code blocks form a FlexE overhead frame. When a transmission instance transmits information on a high-speed physical interface, pad code blocks (i.e., filler blocks) are periodically inserted into each transmission instance. The pad code blocks can be used for speed adjustment. The 257-bit code blocks of multiple transmission instances are then block-interleaved, and the block-interleaved result (i.e., the first target information) is then transmitted on the physical interface. The transmission speed of each transmission instance is 100Gbit / s. When sent on a 200Gbit / s physical interface, 257-bit code blocks of two transmission instances are block-interleaved and then sent on the physical interface with a rate of 200Gbit / s; when sent on a 400Gbit / s physical interface, 257-bit code blocks of four transmission instances are block-interleaved and then sent on the physical interface with a rate of 400Gbit / s; when sent on an 800Gbit / s physical interface, 257-bit code blocks of eight transmission instances are block-interleaved and then sent on the physical interface with a rate of 800Gbit / s; when sent on a 1.6Tbit / s (i.e., 1600Gbit / s) physical interface, 257-bit code blocks of 16 transmission instances are block-interleaved and then sent on the physical interface with a rate of 1600Gbit / s. In one embodiment, in terms of implementation, the 16 transmission instances can be divided into two groups, with 8 transmission instances in each group. The 257-bit code blocks of each group of 8 transmission instances are interleaved to form 800Gbit / s rate code blocks, and then the two groups of 800Gbit / s rate code blocks are interleaved to form a 1600Gbit / s code block stream, which is then sent on the physical interface at a rate of 1600Gbit / s.
[0103] Referring to Figure 28, Figure 28 is a flowchart of a service processing method provided by another embodiment of the present application. The service processing method can be executed by an intermediate device, and the service processing method can include but is not limited to steps S2810 to S2820.
[0104] Step S2810: Extract a first code block stream from the received first target information, wherein the first code block stream is obtained by transcoding a 66-bit code block stream, the 66-bit code block stream is obtained by 64B / 66B encoding the service stream, and the number of bits of the first code block in the first code block stream is greater than 66.
[0105] Step S2820: Map the first code block stream to a second transmission container and send the second transmission container, where the second transmission container includes an overhead code block and a time slot code block. The number of bits of the overhead code block and the number of bits of the time slot code block are both consistent with the number of bits of the first code block. The overhead code block carries overhead information, and the time slot code block carries the first code block.
[0106] In a feasible implementation, the first target information may be ordinary Ethernet service information or high quality of service service information. For example, the high quality of service service information may be CBR service, high quality of service Ethernet service information (such as eCPRI service information), voice service information, video service information, game service information, etc., which is not specifically limited here. The high quality of service service information may be encapsulated in various formats, such as eCPRI protocol message format or Ethernet packet format, etc.; ordinary Ethernet service information may be download service information, etc., which is not specifically limited here.
[0107] In a feasible implementation, the first target information may be obtained by the transmitting device mapping the first code block stream to the first transmission containers carried by multiple transmission instances and then performing code block interleaving on the first transmission containers carried by multiple transmission instances. Therefore, the received first target information may be sent by the transmitting device.
[0108] In a feasible implementation, the transcoding performed on the 66-bit code block stream may be 66B / 257B encoding, so that the first code block in the obtained first code block stream may be a code block with a length of 257 bits.
[0109] In one possible implementation, a time slot code block is a code block transmitted in one time slot.
[0110] In a feasible implementation, the overhead code block may include a first overhead code block and a second overhead code block, and a fixed number of time slot code blocks are spaced between the overhead code blocks in the second transmission container, for example, 4*1023*5 time slot code blocks are spaced between the overhead code blocks in the second transmission container. In addition, the second transmission container may be arranged in the order of a first overhead code block, multiple time slot code blocks, a second overhead code block, and multiple time slot code blocks. The first overhead code block may carry the overhead content of the first four overhead blocks in the FlexE overhead frame, and the second overhead code block may carry the overhead content of the last four overhead blocks in the FlexE overhead frame. In one embodiment, the first overhead code block, the time slot code block, and the second overhead code block may all be code blocks with a length of 257 bits. Therefore, the second transmission container arranged in the order of a first overhead code block, multiple time slot code blocks, a second overhead code block, and multiple time slot code blocks can form a new FlexE frame based on a 257-bit length provided in an embodiment of the present application.
[0111] In a feasible implementation, the first overhead code block may include a first synchronization header, a first code block type field, a first overhead field, a second overhead field, a third overhead field, and a fourth overhead field. The content of the first code block type field may be used to indicate the content type of the first overhead field, the second overhead field, the third overhead field, and the fourth overhead field. The first overhead field may carry the overhead content of the first overhead block in the FlexE overhead frame, the second overhead field may carry the overhead content of the second overhead block in the FlexE overhead frame, the third overhead field may carry the overhead content of the third overhead block in the FlexE overhead frame, and the fourth overhead field may carry the overhead content of the fourth overhead block in the FlexE overhead frame. The first overhead field may include a first overhead field and a second overhead field. The first overhead field may carry part of the first byte of the first overhead block in the FlexE overhead frame, and the second overhead field may carry the last seven bytes of the first overhead block in the FlexE overhead frame.
[0112] In a feasible implementation manner, when the last four overhead blocks in the FlexE overhead frame are all data blocks, the second overhead code block may include a second synchronization header, a fifth overhead field, a sixth overhead field, a seventh overhead field and an eighth overhead field, wherein the fifth overhead field can carry the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field can carry the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field can carry the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field can carry the overhead content of the eighth overhead block in the FlexE overhead frame.
[0113] In a feasible implementation manner, when there is a control block in the last four overhead blocks in the FlexE overhead frame, the second overhead code block may include a second synchronization header, a second code block type field, a fifth overhead field, a sixth overhead field, a seventh overhead field and an eighth overhead field, wherein the content of the second code block type field can be used to indicate the content type of the fifth overhead field, the sixth overhead field, the seventh overhead field and the eighth overhead field, the fifth overhead field can carry the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field can carry the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field can carry the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field can carry the overhead content of the eighth overhead block in the FlexE overhead frame.
[0114] In a feasible embodiment, when the first overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the fifth overhead block in the FlexE overhead frame is a control block, the fifth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the fifth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the fifth overhead block in the FlexE overhead frame.
[0115] In a feasible embodiment, when the second overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the sixth overhead block in the FlexE overhead frame is a control block, the sixth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the sixth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the sixth overhead block in the FlexE overhead frame.
[0116] In a feasible implementation, when the third overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the seventh overhead block in the FlexE overhead frame is a control block, the seventh overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the seventh overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the seventh overhead block in the FlexE overhead frame.
[0117] In a feasible implementation, when the fourth overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the eighth overhead block in the FlexE overhead frame is a control block, the eighth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the eighth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the eighth overhead block in the FlexE overhead frame.
[0118] In this embodiment, by adopting a service processing method including the above-mentioned steps S2810 to S2820, after extracting the first code block stream from the received first target information, the first code block stream can be directly mapped to the second transmission container and the second transmission container is sent. That is, in this process, there is no need to convert the 257-bit code block to the 66-bit code block, nor is there any need to convert the 66-bit code block to the 257-bit code block. Therefore, the code block format between the high-speed Ethernet interface and the FlexE protocol layer can be unified, thereby effectively reducing the cost of the processing circuit. In addition, since the number of bits of the overhead code block and the number of bits of the time slot code block in the second transmission container are consistent with the number of bits of the first code block, and the overhead code block carries overhead information and the time slot code block carries the first code block, more service information can be carried in the time slot code block, thereby increasing the transmission bandwidth of a single time slot, reducing the number of processed time slots, and thus improving the efficiency of data processing.
[0119] In one embodiment, when mapping the first code block stream to the second transmission container, target idle code blocks may be inserted or deleted from the first code block stream to obtain a rate-adapted first code block stream, where the number of bits of the target idle code blocks is consistent with the number of bits of the first code blocks. The rate-adapted first code block stream is then mapped to the second transmission container. Inserting or deleting target idle code blocks from the first code block stream adjusts the speed of the first code block stream, thereby achieving rate adaptation between the second transmission container and the bearer timeslot, thereby improving the transmission efficiency of the second transmission container.
[0120] In one embodiment, when there is no target idle code block in the first code block stream, but there are multiple 66-bit idle code blocks in the 66-bit code block stream, when deleting the target idle code block from the first code block stream, the first code block stream can be first reversed to obtain a 66-bit code block stream, and then the multiple 66-bit idle code blocks in the 66-bit code block stream are position-adjusted to obtain a 66-bit code block stream obtained by aggregating the multiple 66-bit idle code blocks, and then the 66-bit code block stream obtained by aggregating the multiple 66-bit idle code blocks is transcoded to obtain a new first code block stream including the multiple target idle code blocks, and then the target idle code blocks are deleted from the new first code block stream. By adjusting the positions of multiple 66-bit idle code blocks to aggregate the multiple 66-bit idle code blocks, the multiple 66-bit idle code blocks can be concentrated together, which is beneficial for converting these 66-bit idle code blocks into target idle code blocks (for example, 257-bit idle code blocks) with the same number of bits as the first code block during transcoding, thereby facilitating the deletion of the generated target idle code blocks and achieving speed adjustment of the first code block stream.
[0121] In one embodiment, the first code block is obtained by transcoding four consecutive 66-bit code blocks. When the last of the four consecutive 66-bit code blocks corresponding to the previous first code block is not a control code block, or the first of the four consecutive 66-bit code blocks corresponding to the next first code block is not a control code block, when inserting the target idle code block into the first code block stream, the first code block stream can be first reversed to obtain a 66-bit code block stream, and then multiple target code block groups consisting of four consecutive 66-bit code blocks that meet preset conditions are determined in the 66-bit code block stream. Then, in the multiple target code block groups, 66-bit idle code blocks are inserted or deleted between the end code block and the start code block, so that the end code block is in the previous target code block group and the start code block is in the next target code block group, to obtain multiple new target code block groups. Then, the multiple new target code block groups are transcoded to obtain a new first code block stream, and the target idle code blocks are inserted into the new first code block stream. The preset condition includes one of the following:
[0122] In the target code block group, the first 66-bit code block is the end code block, the second 66-bit code block is the start code block, and the third 66-bit code block and the fourth 66-bit code block are code blocks of any type;
[0123] In the target code block group, the first 66-bit code block is the end code block, the second 66-bit code block and the fourth 66-bit code block are code blocks of any type, and the third 66-bit code block is the end code block;
[0124] In the target code block group, the first 66-bit code block is the end code block, the second 66-bit code block and the third 66-bit code block are code blocks of any type, and the fourth 66-bit code block is the start code block;
[0125] In the target code block group, the first 66-bit code block and the fourth 66-bit code block are code blocks of any type, the second 66-bit code block is the end code block, and the third 66-bit code block is the start code block;
[0126] In the target code block group, the first 66-bit code block and the third 66-bit code block are code blocks of any type, the second 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block;
[0127] In the target code block group, the first 66-bit code block and the second 66-bit code block are code blocks of any type, the third 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block.
[0128] In one embodiment, when extracting the first code block stream from the received first target information, since the first target information is obtained by performing code block interleaving on the first transmission containers carried by the multiple transmission instances after mapping the first code block stream to the first transmission containers carried by the multiple transmission instances, the received first target information can be first code block deinterleaved to obtain multiple first transmission containers, and then the first code block stream can be extracted from the multiple first transmission containers. It should be noted that in one embodiment, when the rate of the Ethernet physical interface is 50Gbit / s, 200Gbit / s, 400Gbit / s, 800Gbit / s, or 1600Gbit / s, the transmitting device will insert padding code blocks into the first transmission container carried by each transmission instance. In this case, after the intermediate device performs code block deinterleaving on the first target information to obtain multiple first transmission containers, it is necessary to perform corresponding padding code block removal processing on these first transmission containers, and then extract the first code block stream from the first transmission container from which the padding code blocks have been removed. In another embodiment, when the rate of the Ethernet physical interface is 100 Gbit / s, the transmitting device may not insert padding code blocks into the first transmission container carried by each transmission instance. Therefore, in this case, after the intermediate device performs code block deinterleaving on the first target information to obtain multiple first transmission containers, it is not necessary to perform corresponding padding code block removal processing on these first transmission containers.
[0129] In one embodiment, when mapping the first code block stream to the second transmission container, the first code block stream may be first mapped to multiple time slot code blocks, the multiple time slot code blocks are then assigned to different transmission instances, and the first overhead code block and the second overhead code block are inserted at preset positions in each transmission instance to obtain a second transmission container carried by the multiple transmission instances, wherein a preset number of time slot code blocks exists between the first overhead code block and the second overhead code block. In one embodiment, the preset number may be 4*1023*5, that is, there are 4*1023*5 time slot code blocks between the first overhead code block and the second overhead code block.
[0130] In one embodiment, after obtaining the second transmission containers carried by multiple transmission instances, the second transmission containers carried by the multiple transmission instances can be block interleaved to obtain second target information including the second transmission containers, and then the second target information is transmitted. It should be noted that in one embodiment, when the Ethernet physical interface rate is 50 Gbit / s, 200 Gbit / s, 400 Gbit / s, 800 Gbit / s, or 1600 Gbit / s, the intermediate device needs to insert padding blocks into the second transmission container carried by each transmission instance before performing block interleaving. In this case, a subsequent receiving device needs to delete the padding blocks after receiving the second target information and performing block deinterleaving on the second target information. In another embodiment, when the Ethernet physical interface rate is 100 Gbit / s, the intermediate device may not insert padding blocks into the second transmission container carried by each transmission instance. In this case, a subsequent receiving device does not need to delete the padding blocks after receiving the second target information and performing block deinterleaving on the second target information.
[0131] It should be noted that in the service processing method performed by the intermediate device provided in the embodiment of the present application, the relevant structural description of the new FlexE frame based on the 257-bit length involved can refer to the relevant description content in the previous embodiment. In order to avoid redundant content, it will not be repeated here.
[0132] The following describes in detail the method for processing services executed by an intermediate device provided in an embodiment of the present application using a specific example.
[0133] In one embodiment, after adopting the new FlexE frame structure and time slot structure provided in the embodiment of the present application, the code block units of the physical interface layer and the FlexE service layer in all devices in the network can be 257-bit code blocks, and the processing objects of all links can also be based on 257-bit code blocks. As shown in Figure 29, the FlexE service layer can use 257-bit code blocks as processing units for framing, time slot position determination, extraction of each service code block, etc., where the service code block is also a 257-bit code block, and then the service is cross-mapped to the corresponding output port. At the sending port, the speed of the service code block can be adjusted by adding or deleting the 257-bit idle code block (i.e., the target idle code block) in the service flow to adapt to the transmission speed of the FlexE frame in the sending direction, and then the speed-adjusted service flow is mapped to the new FlexE frame based on the 257-bit length of the sending port, and finally sent out at the sending port. In the embodiment of the present application, since all processing links are executed using 257-bit code blocks as processing units, there is no need to convert 257-bit code blocks to 66-bit code blocks or 66-bit code blocks to 257-bit code blocks. This allows the code block format between the high-speed Ethernet interface and the FlexE protocol layer to be unified, thereby effectively reducing the cost of the processing circuit.
[0134] In one embodiment, the structure of a 66-bit idle code block (a 66-bit idle code block) can be as shown in the upper figure of FIG30 . The 66-bit idle code block consists of a synchronization header "10", a type control word field "01xE", and 56 zero bits. The type control word field consists of two four-bit bits, namely "0x1" and "0xE". In the 66-bit code block (including the 66-bit idle code block), all bits are arranged in reverse order. When "0x1E" is divided into "0x1" and "0xE", the order of the two bits needs to be reversed. As shown in the lower figure of FIG30 , the positive order of the four bits of "0x1" is 0001, which needs to be presented in reverse order in the 66-bit code block, that is, 1000; similarly, the positive order of the four bits of "0xE" is 1110, which needs to be presented in reverse order in the 66-bit code block, that is, 0111. As shown in Figure 31, a 257-bit idle block is encoded from four 66-bit idle blocks. The structure of a 257-bit idle block is as follows: a synchronization header of "0" (located in bit 0), a four-bit type value of "0000" (located in bits 1 to 4), a four-bit characteristic value of "0xE" (located in bits 5 to 8), three eight-bit characteristic values of "0x1E" ("0xE" and "0x1" respectively, located in bits 65 to 72, bits 129 to 136, and bits 193 to 200), and four sets of content values (all 0, located in bits 9 to 61, bits 73 to 128, bits 137 to 192, and bits 201 to 256). When an idle code block needs to be deleted, if the synchronization header in a 257-bit code block is "0" (located at bit0), the four-bit type value is "0000" (located at bit1 to bit4), the four-bit characteristic value is "0xE" (located at bit5 to bit8), and the three eight-bit characteristic values are "0x1E" (respectively "0xE" and "0x1", located at bit65 to bit72, bit129 to bit136, and bit193 to bit200), then the code block can be considered to be a 257-bit idle code block and the deletion operation can be performed. When inserting a 257-bit idle code block, if the four-bit type value in the previous 257-bit code block is "xxx0" (located from bit 1 to bit 4, that is, the last 66-bit code block is a control type code block), and the four-bit type value in the next 257-bit code block is "0xxx" (located from bit 1 to bit 4, that is, the first 66-bit code block is a control type code block), then a 257-bit idle code block can be inserted between the two 257-bit code blocks, as shown in Figure 32.In this way, 257-bit idle blocks can be inserted or deleted in a 257-bit block stream to adjust the service flow rate. When an idle block needs to be deleted, if a 257-bit idle block is determined to exist in the 257-bit service flow (a 257-bit block converted from four 66-bit idle blocks, i.e., the target idle block), the 257-bit idle block can be directly deleted. In some scenarios, only some of the four 66-bit code blocks in a 257-bit code block may be idle code blocks, but the situation will never occur where all four 66-bit code blocks in a 257-bit code block are 66-bit idle code blocks, that is, there will never be an idle code block with a length of 257 bits. This will make it impossible to perform the operation of deleting the idle code blocks with a length of 257 bits. In this case, for example, as shown in Figure 33, the 66-bit idle code blocks in multiple consecutive 257-bit code blocks can be positioned and moved so that the 66-bit idle code blocks in multiple different positions can be concentrated, so that the four 66-bit code blocks in a 257-bit code block are all 66-bit idle code blocks, that is, idle code blocks with a length of 257 bits are formed. In this way, the deletion process of the idle code blocks with a length of 257 bits can be performed. Furthermore, in actual application scenarios, when there are no 257-bit idle code blocks, the 257-bit code blocks can be reversed to 66-bit code blocks. The 66-bit idle code blocks can then be deleted from the 66-bit code block stream. After deleting an appropriate number of 66-bit idle code blocks, the remaining 66-bit code blocks can be transcoded to 257-bit code blocks. If the sending end has already performed 257-bit code block rate adjustment and implemented the addition and deletion of 257-bit idle code blocks before mapping the service to the master calendar, then the conditions for adding and deleting 257-bit idle code blocks will be met when the service flow passes through any intermediate device on the network, allowing the addition and deletion of 257-bit idle code blocks to be directly performed. If only 66-bit idle code blocks are added or deleted before the sending end service is mapped to the master calendar, and no speed adjustment is performed on the 257-bit code blocks, and no special position adjustment is performed on the four 66-bit code blocks of the encoding object during 66B / 257B encoding (i.e., the position adjustment or movement of the 66-bit idle code blocks), then when the service flow passes through any intermediate devices on the network, these intermediate devices may not be able to directly add or delete 257-bit idle code blocks.
[0135] Referring to Figure 34, Figure 34 is a flowchart of a service processing method provided by another embodiment of the present application. The service processing method can be executed by a receiving device, and the service processing method may include but is not limited to steps S3410 to S3430.
[0136] Step S3410: Extract a third transmission container from the received third target information, and extract the first code block stream from the third transmission container, wherein the third transmission container includes overhead code blocks and time slot code blocks, the number of bits of the overhead code blocks and the number of bits of the time slot code blocks are consistent with the number of bits of the first code blocks in the first code block stream, the overhead code blocks carry overhead information, the time slot code blocks carry the first code blocks, the first code block stream is obtained by transcoding a 66-bit code block stream, the 66-bit code block stream is obtained by performing 64B / 66B encoding on the service stream, and the number of bits of the first code block is greater than 66.
[0137] Step S3420: Reverse the first code block stream to obtain a 66-bit code block stream;
[0138] Step S3430: Perform 64B / 66B decoding on the 66-bit code block stream to obtain the service stream.
[0139] In a feasible implementation, the third target information may be ordinary Ethernet service information or high quality of service service information. For example, the high quality of service service information may be CBR service, high quality of service Ethernet service information (such as eCPRI service information), voice service information, video service information, game service information, etc., which is not specifically limited here. The high quality of service service information may be encapsulated in various formats, such as eCPRI protocol message format or Ethernet packet format, etc.; ordinary Ethernet service information may be download service information, etc., which is not specifically limited here.
[0140] In a feasible implementation, the third target information may be obtained by, after the transmitting device maps the first code block stream to the first transmission containers carried by multiple transmission instances, performing code block interleaving on the first transmission containers carried by multiple transmission instances. Therefore, the received third target information may be sent by the transmitting device, that is, the third target information may be the first target information described above. In this case, the third transmission container may be the first transmission container described above.
[0141] In a feasible implementation, the third target information may also be obtained by the intermediate device mapping the first code block stream to the second transmission containers carried by multiple transmission instances and then performing code block interleaving on the second transmission containers carried by multiple transmission instances. Therefore, the received third target information may also be sent by the intermediate device. That is, the third target information may be the second target information described above. In this case, the third transmission container may be the second transmission container described above.
[0142] In a feasible implementation, the transcoding performed on the 66-bit code block stream may be 66B / 257B encoding, so that the first code block in the obtained first code block stream may be a code block with a length of 257 bits.
[0143] In one possible implementation, a time slot code block is a code block transmitted in one time slot.
[0144] In a feasible implementation, the overhead code block may include a first overhead code block and a second overhead code block, and a fixed number of time slot code blocks are spaced between the overhead code blocks in the third transmission container, for example, 4*1023*5 time slot code blocks are spaced between the overhead code blocks in the third transmission container. In addition, the third transmission container may be arranged in the order of a first overhead code block, multiple time slot code blocks, a second overhead code block, and multiple time slot code blocks. The first overhead code block may carry the overhead content of the first four overhead blocks in the FlexE overhead frame, and the second overhead code block may carry the overhead content of the last four overhead blocks in the FlexE overhead frame. In one embodiment, the first overhead code block, the time slot code block, and the second overhead code block may all be code blocks with a length of 257 bits. Therefore, the third transmission container arranged in the order of a first overhead code block, multiple time slot code blocks, a second overhead code block, and multiple time slot code blocks can form a new FlexE frame based on a 257-bit length provided in an embodiment of the present application.
[0145] In a feasible implementation manner, there are 4*1023*5 time slot code blocks between the first overhead code block and the second overhead code block.
[0146] In a feasible implementation, the first overhead code block may include a first synchronization header, a first code block type field, a first overhead field, a second overhead field, a third overhead field, and a fourth overhead field. The content of the first code block type field may be used to indicate the content type of the first overhead field, the second overhead field, the third overhead field, and the fourth overhead field. The first overhead field may carry the overhead content of the first overhead block in the FlexE overhead frame, the second overhead field may carry the overhead content of the second overhead block in the FlexE overhead frame, the third overhead field may carry the overhead content of the third overhead block in the FlexE overhead frame, and the fourth overhead field may carry the overhead content of the fourth overhead block in the FlexE overhead frame. The first overhead field may include a first overhead field and a second overhead field. The first overhead field may carry part of the first byte of the first overhead block in the FlexE overhead frame, and the second overhead field may carry the last seven bytes of the first overhead block in the FlexE overhead frame.
[0147] In a feasible implementation manner, when the last four overhead blocks in the FlexE overhead frame are all data blocks, the second overhead code block may include a second synchronization header, a fifth overhead field, a sixth overhead field, a seventh overhead field and an eighth overhead field, wherein the fifth overhead field can carry the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field can carry the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field can carry the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field can carry the overhead content of the eighth overhead block in the FlexE overhead frame.
[0148] In a feasible implementation manner, when there is a control block in the last four overhead blocks in the FlexE overhead frame, the second overhead code block may include a second synchronization header, a second code block type field, a fifth overhead field, a sixth overhead field, a seventh overhead field and an eighth overhead field, wherein the content of the second code block type field can be used to indicate the content type of the fifth overhead field, the sixth overhead field, the seventh overhead field and the eighth overhead field, the fifth overhead field can carry the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field can carry the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field can carry the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field can carry the overhead content of the eighth overhead block in the FlexE overhead frame.
[0149] In a feasible embodiment, when the first overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the fifth overhead block in the FlexE overhead frame is a control block, the fifth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the fifth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the fifth overhead block in the FlexE overhead frame.
[0150] In a feasible embodiment, when the second overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the sixth overhead block in the FlexE overhead frame is a control block, the sixth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the sixth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the sixth overhead block in the FlexE overhead frame.
[0151] In a feasible implementation, when the third overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the seventh overhead block in the FlexE overhead frame is a control block, the seventh overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the seventh overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the seventh overhead block in the FlexE overhead frame.
[0152] In a feasible implementation, when the fourth overhead block of the last four overhead blocks in the FlexE overhead frame is a control block, that is, when the eighth overhead block in the FlexE overhead frame is a control block, the eighth overhead field may include a third overhead field and a fourth overhead field, wherein the third overhead field may carry part of the first byte content of the eighth overhead block in the FlexE overhead frame, and the fourth overhead field may carry the last seven bytes of the eighth overhead block in the FlexE overhead frame.
[0153] In this embodiment, by adopting the service processing method including steps S3410 to S3430 described above, after extracting the third transmission container from the received third target information, the first code block stream is extracted from the third transmission container, and then the first code block stream is reversed to recover a 66-bit code block stream. The 66-bit code block stream is then 64B / 66B decoded to recover the service stream. Because the third transmission container includes overhead code blocks and time slot code blocks, wherein the number of bits in the overhead code blocks and the number of bits in the time slot code blocks are both consistent with the number of bits in the first code block in the first code block stream, and the overhead code blocks carry overhead information and the time slot code blocks carry the first code blocks, more service information can be carried in the time slot code blocks, thereby increasing the transmission bandwidth of a single time slot, reducing the number of time slots to be processed, and thereby improving data processing efficiency.
[0154] In one embodiment, when there are multiple third transmission containers, when extracting the third transmission container from the received third target information, block deinterleaving may be performed on the received third target information to obtain multiple third transmission containers. In the process of performing block deinterleaving on the received third target information to obtain multiple third transmission containers, block deinterleaving may be performed on the received third target information to obtain multiple second candidate transmission containers. Then, padding blocks may be deleted from the multiple second candidate transmission containers to obtain multiple third transmission containers, where the number of bits in the padding blocks is the same as the number of bits in the first code blocks.
[0155] It should be noted that, in one embodiment, when the Ethernet physical interface rate is 50 Gbit / s, 200 Gbit / s, 400 Gbit / s, 800 Gbit / s, or 1600 Gbit / s, the transmitting device or intermediate device may insert padding blocks into the third transmission container (i.e., the first transmission container or the second transmission container) carried by each transmission instance. In this case, after the receiving device performs block deinterleaving on the third target information (i.e., the first target information or the second target information) to obtain multiple second candidate transmission containers, it is necessary to perform corresponding padding block removal on these second candidate transmission containers. In another embodiment, when the Ethernet physical interface rate is 100 Gbit / s, since the transmitting device or intermediate device may not insert padding blocks into the third transmission container carried by each transmission instance, in this case, after the receiving device performs block deinterleaving on the third target information to obtain multiple second candidate transmission containers, it is not necessary to perform corresponding padding block removal on these second candidate transmission containers.
[0156] It should be noted that in the service processing method performed by the receiving device provided in the embodiment of the present application, the relevant structural description of the new FlexE frame based on the 257-bit length involved can refer to the relevant description content in the previous embodiment. In order to avoid redundant content, it will not be repeated here.
[0157] The following describes in detail the method for processing services executed by a receiving device provided in an embodiment of the present application using a specific example.
[0158] As shown in Figure 35, in the receiving device, when each high-speed physical interface receives a service flow (for example, the first target information sent by the transmitting device or the second target information sent by the intermediate device), the 257-bit code block is first restored in the service flow to obtain a high-speed 257-bit code block stream, and then the high-speed 257-bit code block stream is code block deinterleaved to obtain a code block stream of a multiple transmission instance (that is, the second candidate transmission container), where each transmission instance has a transmission rate of 100Gbit / s. For example, block deinterleaving is performed on a 257-bit code block stream on a 200 Gbit / s physical interface to obtain a code block stream for two transmission instances; or block deinterleaving is performed on a 257-bit code block stream on a 400 Gbit / s physical interface to obtain a code block stream for four transmission instances; or block deinterleaving is performed on a 257-bit code block stream on an 800 Gbit / s physical interface to obtain a code block stream for eight transmission instances; or block deinterleaving is performed on a 257-bit code block stream on a 1600 Gbit / s physical interface to obtain a code block stream for sixteen transmission instances. Alternatively, the 257-bit block stream on the 1600 Gbit / s physical interface may be block deinterleaved to obtain two block streams each with a transmission rate of 800 Gbit / s. The structures of these two block streams with a transmission rate of 800 Gbit / s are consistent with the block stream of the 800 Gbit / s physical interface. The 800 Gbit / s block stream is then block deinterleaved again to obtain a block stream for 8 transmission instances. Next, the pad blocks (i.e., filler blocks) are stripped and deleted from the block stream of each transmission instance. The overhead blocks are then searched and located in each transmission instance, and alignment is performed using the overhead blocks as a benchmark. All time slot blocks of the master calendar (shim layer) are sequentially restored in the time slot member arrangements of all transmission instances, where each time slot block is 257 bits long. The 257-bit code blocks of the service are then extracted from the corresponding time slot blocks based on the bearer time slot selected by the service. The 257-bit code blocks are then reversed (e.g., 66B / 257B decoding) to restore a 66-bit code block stream. This 66-bit code block stream is then 64B / 66B decoded to restore the original service stream.
[0159] In addition, an embodiment of the present application further discloses a network device, which includes a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the computer program, it implements a service processing method as in any of the previous embodiments.
[0160] In addition, an embodiment of the present application further discloses a computer-readable storage medium, in which computer-executable instructions are stored. The computer-executable instructions are used to execute the service processing method in any of the previous embodiments.
[0161] In addition, an embodiment of the present application also discloses a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. The processor of the network device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the network device performs a service processing method as in any of the previous embodiments.
[0162] Those skilled in the art will appreciate that all or some of the steps and systems in the method disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include computer storage media (or non-transitory media) and communication media (or temporary media). As known to those skilled in the art, the term computer storage media is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data) and is volatile and non-volatile, removable, and non-removable. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage, or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.
[0163] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above implementation mode. Technical personnel familiar with the field can also make various equivalent modifications or substitutions without violating the spirit of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.
Claims
1. A method for processing a service, comprising: Performing 64B / 66B encoding on a service flow to obtain a 66-bit code block stream; Transcoding the 66-bit code block stream to obtain a first transcoded code block stream, wherein the number of bits of the first code block in the first code block stream is greater than 66; Mapping the first code block stream to a first transport container and sending the first transport container, wherein the first transport container includes an overhead code block and a time slot code block, and the number of bits of the overhead code block and the number of bits of the time slot code block are both consistent with the number of bits of the first code block, the overhead code block carries overhead information, and the time slot code block carries the first code block.
2. The method according to claim 1, wherein, The overhead code block includes a first overhead code block and a second overhead code block, and there is a fixed number of the time slot code blocks between the overhead code blocks in the first transport container.
3. The method according to claim 2, wherein The first overhead code block carries the overhead content of the first four overhead blocks in the FlexE overhead frame, and the second overhead code block carries the overhead content of the last four overhead blocks in the FlexE overhead frame.
4. The method according to claim 3, wherein, The first overhead code block includes a first synchronization header, a first code block type field, a first overhead field, a second overhead field, a third overhead field, and a fourth overhead field. The content of the first code block type field is used to indicate the content types of the first overhead field, the second overhead field, the third overhead field, and the fourth overhead field. The first overhead field carries the overhead content of the first overhead block in the FlexE overhead frame, the second overhead field carries the overhead content of the second overhead block in the FlexE overhead frame, the third overhead field carries the overhead content of the third overhead block in the FlexE overhead frame, and the fourth overhead field carries the overhead content of the fourth overhead block in the FlexE overhead frame.
5. The method according to claim 4, wherein The first overhead field includes a first overhead sub-field and a second overhead sub-field. The first overhead sub-field carries a part of the content of the first byte of the first overhead block in the FlexE overhead frame, and the second overhead sub-field carries the content of the last seven bytes of the first overhead block in the FlexE overhead frame.
6. The method according to claim 3, wherein When the last four overhead blocks in the FlexE overhead frame are all data blocks, the second overhead code block includes a second synchronization header, a fifth overhead field, a sixth overhead field, a seventh overhead field, and an eighth overhead field. The fifth overhead field carries the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field carries the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field carries the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field carries the overhead content of the eighth overhead block in the FlexE overhead frame.
7. The method according to claim 3, wherein, When there is a control block in the last four overhead blocks of the FlexE overhead frame, the second overhead code block includes a second synchronization header, a second code block type field, a fifth overhead field, a sixth overhead field, a seventh overhead field, and an eighth overhead field. The content of the second code block type field is used to indicate the content types of the fifth overhead field, the sixth overhead field, the seventh overhead field, and the eighth overhead field. The fifth overhead field carries the overhead content of the fifth overhead block in the FlexE overhead frame. The sixth overhead field carries the overhead content of the sixth overhead block in the FlexE overhead frame. The seventh overhead field carries the overhead content of the seventh overhead block in the FlexE overhead frame. The eighth overhead field carries the overhead content of the eighth overhead block in the FlexE overhead frame.
8. The method according to claim 7, wherein: The fifth overhead field includes a third overhead field and a fourth overhead field. The third overhead field carries a partial content of the first byte content of the fifth overhead block in the FlexE overhead frame. The fourth overhead field carries the content of the last seven bytes of the fifth overhead block in the FlexE overhead frame. Or, The sixth overhead field includes a third overhead field and a fourth overhead field. The third overhead field carries a partial content of the first byte content of the sixth overhead block in the FlexE overhead frame. The fourth overhead field carries the content of the last seven bytes of the sixth overhead block in the FlexE overhead frame. Or, The seventh overhead field includes a third overhead field and a fourth overhead field. The third overhead field carries a partial content of the first byte content of the seventh overhead block in the FlexE overhead frame. The fourth overhead field carries the content of the last seven bytes of the seventh overhead block in the FlexE overhead frame. Or, The eighth overhead field includes a third overhead field and a fourth overhead field. The third overhead field carries a partial content of the first byte content of the eighth overhead block in the FlexE overhead frame. The fourth overhead field carries the content of the last seven bytes of the eighth overhead block in the FlexE overhead frame.
9. The method according to claim 1, wherein The transcoding of the 66-bit code block stream to obtain the transcoded first code block stream includes: Inserting or deleting 66-bit idle code blocks from the 66-bit code block stream to obtain the speed-adapted 66-bit code block stream; Transcoding the speed-adapted 66-bit code block stream to obtain the transcoded first code block stream.
10. The method according to claim 9, wherein, The transcoding of the speed-adapted 66-bit code block stream to obtain the transcoded first code block stream includes: Adjusting the positions of multiple 66-bit idle code blocks in the speed-adapted 66-bit code block stream to obtain the 66-bit code block stream after aggregating multiple 66-bit idle code blocks; Transcoding the 66-bit code block stream after aggregating multiple 66-bit idle code blocks to obtain the transcoded first code block stream.
11. The method according to claim 1, wherein, During the transcoding of the 66-bit code block stream, the following steps are included: Insert or delete 66-bit idle code blocks in the 66-bit code block stream to obtain a group of idle code blocks composed of four consecutive 66-bit idle code blocks; Transcode the group of idle code blocks to obtain target idle code blocks, where the number of bits of the target idle code blocks is the same as that of the first code block.
12. The method according to claim 1, wherein, During the transcoding of the 66-bit code block stream, when one of the following situations exists in four consecutive 66-bit code blocks used for the same transcoding, insert or delete 66-bit idle code blocks between the end code block and the start code block, so that the end code block is in the four consecutive 66-bit code blocks of the previous transcoding, and the start code block is in the four consecutive 66-bit code blocks of the next transcoding: In the four consecutive 66-bit code blocks, the first 66-bit code block is the end code block, the second 66-bit code block is the start code block, and the third and fourth 66-bit code blocks are both code blocks of any type; In the four consecutive 66-bit code blocks, the first 66-bit code block is the end code block, the second and fourth 66-bit code blocks are both code blocks of any type, and the third 66-bit code block is the end code block; In the four consecutive 66-bit code blocks, the first 66-bit code block is the end code block, the second and third 66-bit code blocks are both code blocks of any type, and the fourth 66-bit code block is the start code block; In the four consecutive 66-bit code blocks, the first and fourth 66-bit code blocks are both code blocks of any type, the second 66-bit code block is the end code block, and the third 66-bit code block is the start code block; In the four consecutive 66-bit code blocks, the first and third 66-bit code blocks are both code blocks of any type, the second 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block; In the four consecutive 66-bit code blocks, the first and second 66-bit code blocks are both code blocks of any type, the third 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block.
13. The method according to claim 12, wherein The mapping of the first code block stream to the first transport container includes: Insert or delete the target idle code blocks in the first code block stream to obtain the first code block stream after speed adaptation, where the number of bits of the target idle code blocks is the same as that of the first code block; Map the first code block stream after speed adaptation to the first transport container.
14. The method according to claim 1, wherein, The mapping of the first code block stream to the first transport container includes: Map the first code block stream to multiple time slot code blocks; Allocate multiple time slot code blocks to different transmission instances, and insert a first overhead code block and a second overhead code block at preset positions in each transmission instance to obtain the first transport container carried by multiple transmission instances, where there is a preset number of time slot code blocks between the first overhead code block and the second overhead code block.
15. The method according to claim 14, wherein The sending of the first transport container includes: Perform codeblock interleaving on the first transport containers carried by multiple said transport instances to obtain first target information including the first transport containers; Transmit the first target information.
16. The method according to claim 15, wherein, The performing codeblock interleaving on the first transport containers carried by multiple said transport instances to obtain first target information including the first transport containers includes: Insert padding codeblocks into the first transport containers carried by each of the transport instances to obtain first candidate transport containers carried by each of the transport instances, where the number of bits of the padding codeblocks is the same as the number of bits of the first codeblocks; Perform codeblock interleaving on the first candidate transport containers carried by multiple said transport instances to obtain first target information including the first transport containers.
17. A method for processing a service, including: Extract a first codeblock stream from the received first target information, where the first codeblock stream is obtained by transcoding a 66-bit codeblock stream, the 66-bit codeblock stream is obtained by performing 64B / 66B encoding on a service stream, and the number of bits of the first codeblocks in the first codeblock stream is greater than 66; Map the first codeblock stream to a second transport container, and transmit the second transport container, where the second transport container includes an overhead codeblock and a time slot codeblock, the number of bits of the overhead codeblock and the number of bits of the time slot codeblock are both the same as the number of bits of the first codeblocks, the overhead codeblock carries overhead information, and the time slot codeblock carries the first codeblocks.
18. The method according to claim 17, wherein The overhead codeblock includes a first overhead codeblock and a second overhead codeblock, and there are a fixed number of the time slot codeblocks between the overhead codeblocks in the second transport container.
19. The method according to claim 18, wherein The first overhead codeblock carries the overhead content of the first four overhead blocks in the FlexE overhead frame, and the second overhead codeblock carries the overhead content of the last four overhead blocks in the FlexE overhead frame.
20. The method according to claim 19, wherein The first overhead codeblock includes a first synchronization header, a first codeblock type field, a first overhead field, a second overhead field, a third overhead field, and a fourth overhead field. The content of the first codeblock type field is used to indicate the content types of the first overhead field, the second overhead field, the third overhead field, and the fourth overhead field. The first overhead field carries the overhead content of the first overhead block in the FlexE overhead frame, the second overhead field carries the overhead content of the second overhead block in the FlexE overhead frame, the third overhead field carries the overhead content of the third overhead block in the FlexE overhead frame, and the fourth overhead field carries the overhead content of the fourth overhead block in the FlexE overhead frame.
21. The method according to claim 20, wherein, The first overhead field includes a first overhead sub-field and a second overhead sub-field. The first overhead sub-field carries a part of the content of the first byte of the first overhead block in the FlexE overhead frame, and the second overhead sub-field carries the content of the last seven bytes of the first overhead block in the FlexE overhead frame.
22. The method according to claim 19, wherein, When the last four overhead blocks in the FlexE overhead frame are all data blocks, the second overhead code block includes a second synchronization header, a fifth overhead field, a sixth overhead field, a seventh overhead field, and an eighth overhead field. The fifth overhead field carries the overhead content of the fifth overhead block in the FlexE overhead frame. The sixth overhead field carries the overhead content of the sixth overhead block in the FlexE overhead frame. The seventh overhead field carries the overhead content of the seventh overhead block in the FlexE overhead frame. The eighth overhead field carries the overhead content of the eighth overhead block in the FlexE overhead frame.
23. The method according to claim 19, wherein, When there is a control block among the last four overhead blocks in the FlexE overhead frame, the second overhead code block includes a second synchronization header, a second code block type field, a fifth overhead field, a sixth overhead field, a seventh overhead field, and an eighth overhead field. The content of the second code block type field is used to indicate the content types of the fifth overhead field, the sixth overhead field, the seventh overhead field, and the eighth overhead field. The fifth overhead field carries the overhead content of the fifth overhead block in the FlexE overhead frame. The sixth overhead field carries the overhead content of the sixth overhead block in the FlexE overhead frame. The seventh overhead field carries the overhead content of the seventh overhead block in the FlexE overhead frame. The eighth overhead field carries the overhead content of the eighth overhead block in the FlexE overhead frame.
24. According to the method described in claim 23, wherein: The fifth overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a part of the content of the first byte of the fifth overhead block in the FlexE overhead frame. The fourth overhead sub - field carries the content of the last seven bytes of the fifth overhead block in the FlexE overhead frame. Or, The sixth overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a part of the content of the first byte of the sixth overhead block in the FlexE overhead frame. The fourth overhead sub - field carries the content of the last seven bytes of the sixth overhead block in the FlexE overhead frame. Or, The seventh overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a part of the content of the first byte of the seventh overhead block in the FlexE overhead frame. The fourth overhead sub - field carries the content of the last seven bytes of the seventh overhead block in the FlexE overhead frame. Or, The eighth overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a part of the content of the first byte of the eighth overhead block in the FlexE overhead frame. The fourth overhead sub - field carries the content of the last seven bytes of the eighth overhead block in the FlexE overhead frame.
25. The method according to claim 17, wherein, The mapping of the first code block stream to the second transport container includes: Inserting or deleting target idle code blocks for the first code block stream to obtain the first code block stream after speed adaptation, where the number of bits of the target idle code block is the same as the number of bits of the first code block. Mapping the first code block stream after speed adaptation to the second transport container.
26. The method according to claim 25, wherein, In the case that the target free code block does not exist in the first code block stream, but there are multiple 66-bit free code blocks in the 66-bit code block stream, the process of deleting the target free code block from the first code block stream includes: Inverse code the first code block stream to obtain the 66-bit code block stream; Adjust the positions of the multiple 66-bit free code blocks in the 66-bit code block stream to obtain the 66-bit code block stream after aggregating the multiple 66-bit free code blocks; Transcode the 66-bit code block stream after aggregating the multiple 66-bit free code blocks to obtain a new first code block stream including multiple target free code blocks; Delete the target free code block from the new first code block stream.
27. The method according to claim 25, wherein The first code block is obtained by transcoding four consecutive 66-bit code blocks; when there is a situation where the last one of the four consecutive 66-bit code blocks corresponding to the previous first code block is not a control code block, or the first one of the four consecutive 66-bit code blocks corresponding to the next first code block is not a control code block, the process of inserting the target free code block into the first code block stream includes: Inverse code the first code block stream to obtain the 66-bit code block stream; Determine multiple target code block groups composed of four consecutive 66-bit code blocks that meet the preset conditions in the 66-bit code block stream; Insert or delete 66-bit free code blocks between the end code block and the start code block in the multiple target code block groups, so that the end code block is in the previous target code block group and the start code block is in the next target code block group, to obtain multiple new target code block groups; Transcode the multiple new target code block groups to obtain a new first code block stream; Insert the target free code block into the new first code block stream; Wherein, the preset conditions include one of the following: In the target code block group, the first 66-bit code block is the end code block, the second 66-bit code block is the start code block, and the third and fourth 66-bit code blocks are both code blocks of any type; In the target code block group, the first 66-bit code block is the end code block, the second and fourth 66-bit code blocks are both code blocks of any type, and the third 66-bit code block is the end code block; In the target code block group, the first 66-bit code block is the end code block, the second and third 66-bit code blocks are both code blocks of any type, and the fourth 66-bit code block is the start code block; In the target code block group, the first and fourth 66-bit code blocks are both code blocks of any type, the second 66-bit code block is the end code block, and the third 66-bit code block is the start code block; In the target code block group, the first and third 66-bit code blocks are both code blocks of any type, the second 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block; In the target code block group, the first 66-bit code block and the second 66-bit code block are both code blocks of any type, the third 66-bit code block is the end code block, and the fourth 66-bit code block is the start code block.
28. The method according to claim 17, wherein, Extracting a first code block stream from the received first target information includes: Performing code block deinterleaving on the received first target information to obtain a plurality of first transport containers; Extracting the first code block stream from the plurality of first transport containers.
29. The method according to claim 17, wherein, Mapping the first code block stream to a second transport container includes: Mapping the first code block stream to a plurality of the time slot code blocks; Allocating the plurality of time slot code blocks to different transmission instances, and inserting a first overhead code block and a second overhead code block at preset positions in each of the transmission instances to obtain second transport containers carried by the plurality of transmission instances, where there is a preset number of the time slot code blocks between the first overhead code block and the second overhead code block.
30. The method according to claim 29, wherein, Sending the second transport container includes: Performing code block interleaving on the second transport containers carried by the plurality of transmission instances to obtain second target information including the second transport containers; Sending the second target information.
31. A method for processing a service, including: Extracting a third transport container from the received third target information, and extracting a first code block stream from the third transport container, where the third transport container includes an overhead code block and a time slot code block, the number of bits of the overhead code block and the number of bits of the time slot code block are both consistent with the number of bits of a first code block in the first code block stream, the overhead code block carries overhead information, the time slot code block carries the first code block, the first code block stream is obtained by transcoding a 66-bit code block stream, the 66-bit code block stream is obtained by performing 64B / 66B encoding on a service stream, and the number of bits of the first code block is greater than 66; Performing reverse transcoding on the first code block stream to obtain the 66-bit code block stream; Performing 64B / 66B decoding on the 66-bit code block stream to obtain the service stream.
32. The method according to claim 31, wherein, The overhead code block includes a first overhead code block and a second overhead code block, and there is a fixed number of the time slot code blocks between the overhead code blocks in the third transport container.
33. The method according to claim 32, wherein, The first overhead code block carries the overhead content of the first four overhead blocks in the FlexE overhead frame, and the second overhead code block carries the overhead content of the last four overhead blocks in the FlexE overhead frame.
34. The method according to claim 33, wherein The first overhead code block includes a first synchronization header, a first code block type field, a first overhead field, a second overhead field, a third overhead field, and a fourth overhead field. The content of the first code block type field is used to indicate the content type of the first overhead field, the second overhead field, the third overhead field, and the fourth overhead field. The first overhead field carries the overhead content of the first overhead block in the FlexE overhead frame, the second overhead field carries the overhead content of the second overhead block in the FlexE overhead frame, the third overhead field carries the overhead content of the third overhead block in the FlexE overhead frame, and the fourth overhead field carries the overhead content of the fourth overhead block in the FlexE overhead frame.
35. The method according to claim 34, wherein, The first overhead field includes a first overhead sub - field and a second overhead sub - field. The first overhead sub - field carries a partial content of the first byte of the first overhead block in the FlexE overhead frame, and the second overhead sub - field carries the content of the last seven bytes of the first overhead block in the FlexE overhead frame.
36. The method according to claim 33, wherein When the last four overhead blocks in the FlexE overhead frame are all data blocks, the second overhead code block includes a second synchronization header, a fifth overhead field, a sixth overhead field, a seventh overhead field, and an eighth overhead field. The fifth overhead field carries the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field carries the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field carries the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field carries the overhead content of the eighth overhead block in the FlexE overhead frame.
37. The method according to claim 33, wherein When there is a control block among the last four overhead blocks in the FlexE overhead frame, the second overhead code block includes a second synchronization header, a second code block type field, a fifth overhead field, a sixth overhead field, a seventh overhead field, and an eighth overhead field. The content of the second code block type field is used to indicate the content type of the fifth overhead field, the sixth overhead field, the seventh overhead field, and the eighth overhead field. The fifth overhead field carries the overhead content of the fifth overhead block in the FlexE overhead frame, the sixth overhead field carries the overhead content of the sixth overhead block in the FlexE overhead frame, the seventh overhead field carries the overhead content of the seventh overhead block in the FlexE overhead frame, and the eighth overhead field carries the overhead content of the eighth overhead block in the FlexE overhead frame.
38. The method according to claim 37, wherein: The fifth overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a partial content of the first byte of the fifth overhead block in the FlexE overhead frame, and the fourth overhead sub - field carries the content of the last seven bytes of the fifth overhead block in the FlexE overhead frame; or The sixth overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a partial content of the first byte of the sixth overhead block in the FlexE overhead frame, and the fourth overhead sub - field carries the content of the last seven bytes of the sixth overhead block in the FlexE overhead frame; or The seventh overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a partial content of the first byte of the seventh overhead block in the FlexE overhead frame, and the fourth overhead sub - field carries the content of the last seven bytes of the seventh overhead block in the FlexE overhead frame; or The eighth overhead field includes a third overhead sub - field and a fourth overhead sub - field. The third overhead sub - field carries a partial content of the first byte of the eighth overhead block in the FlexE overhead frame, and the fourth overhead sub - field carries the content of the last seven bytes of the eighth overhead block in the FlexE overhead frame.
39. The method according to claim 31, wherein, The number of the third transport containers is multiple. Extracting the third transport container from the received third target information includes: Perform code block deinterleaving on the received third target information to obtain a plurality of the third transport containers.
40. The method according to claim 39, wherein, The performing code block deinterleaving on the received third target information to obtain a plurality of the third transport containers includes: Perform code block deinterleaving on the received third target information to obtain a plurality of second candidate transport containers; Delete padded code blocks from the plurality of the second candidate transport containers to obtain a plurality of the third transport containers, wherein the number of bits of the padded code blocks is the same as the number of bits of the first code blocks.
41. A network device, comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, it implements the processing method of the service according to any one of claims 1 to 40.
42. A computer-readable storage medium storing computer-executable instructions for executing the processing method of the service according to any one of claims 1 to 40.
Citation Information
Patent Citations
Method for data transmission, transmitter and receiver
CN106411454A
Service processing method, device and equipment
CN113645524A
Data processing method, device, equipment, system and computer readable storage medium
CN116743677A