Traffic information processing method, network device, and storage medium

Abstract

The present application provides a traffic information processing method, a network device, and a storage medium, which includes: mapping first traffic information to a first cell and transmitting the first cell (S110); locating second traffic information at a location of a second cell and transmitting the second traffic information at the location of the second cell (S120).

Description

[Technical Field]

[0001] This application is filed based on a Chinese patent application bearing application number 202210968517.4 and filed on August 12, 2022, and claims priority to that Chinese patent application, the entire contents of which are incorporated herein by reference.

[0002] TECHNICAL FIELD Embodiments of the present application relate to, but are not limited to, the technical field of communications, and in particular to a method for processing traffic information, a network device, and a storage medium. [Background technology]

[0003] In network communications, there are two types of traffic: high-quality traffic and normal Ethernet traffic. High-quality traffic requires its own bearer pipeline, and for example, some cells can be carried independently. Normal Ethernet traffic does not require its own bearer pipeline, for example, multiple normal Ethernet traffic packets can be carried by one cell. However, in related technologies, before carrying normal Ethernet traffic, the normal Ethernet traffic information must be 64B / 66B encoded, the encoded 66-bit code block converted into a bit stream or bytes, and then mapped into the payload area of a cell for carrying the traffic. This process complicates the cell's traffic carrying, reduces the cell's bearer efficiency, and is therefore prone to bandwidth waste. Summary of the Invention [Problem to be solved by the invention]

[0004] The embodiments of the present application provide a method for processing traffic information, a network device, and a storage medium. [Means for solving the problem]

[0005] In a first aspect, an embodiment of the present application provides a method for processing traffic information, including the steps of mapping first traffic information to a first cell and transmitting the first cell, and locating second traffic information at a location of a second cell and transmitting the second traffic information at the location of the second cell.

[0006] In a second aspect, an embodiment of the present application further provides a network device including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor, when executing the computer program, realizes the above-mentioned method for processing traffic information.

[0007] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions for performing the above traffic information processing method.

[0008] In a fourth aspect, an embodiment of the present application further provides a computer program product including a computer program or computer instructions stored in a computer-readable storage medium, wherein a processor of a computer 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 to cause the computer device to perform the above-mentioned traffic information processing method. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 2 is a schematic diagram of bearers in a cell for high quality of service traffic and Ethernet traffic according to one embodiment of the present application; [Figure 2] 2 is a flowchart of a method for processing traffic information according to an embodiment of the present application; [Figure 3] 1 is a schematic diagram of bearers in a cell of traffic information of an Ethernet Universal Public Radio Interface according to an example of the present application; [Figure 4] FIG. 1 is a schematic diagram of a cell structure according to an example of the present application. [Figure 5] FIG. 2 is a schematic diagram of a cell structure according to another example of the present application. [Figure 6] FIG. 10 is a schematic diagram illustrating a case where a sequence number is included in a cell according to an embodiment of the present application. [Figure 7] 3 is a flowchart of the method of step S120 of FIG. 2. [Figure 8] 10 is a flowchart of fragment encoding of second traffic information according to an embodiment of the present application; [Figure 9] FIG. 10 is a schematic diagram illustrating when the lengths of two adjacent encoded fragment information pieces are not equal according to an embodiment of the present application; [Figure 10] 8 is a flowchart of the method of step S210 of FIG. 7. [Figure 11] FIG. 2 is a schematic diagram of cell locations corresponding to first traffic information and second traffic information according to an embodiment of the present application; [Figure 12] FIG. 10 is a schematic diagram illustrating canceling a start code block and an end code block between two adjacent target coded fragment information according to an embodiment of the present application; [Figure 13] FIG. 10 is a schematic diagram of encoded fragment information when there is no target packet according to one embodiment of the present application; [Figure 14] 2 is a schematic diagram of a start code block of typical Ethernet traffic information according to one embodiment of the present application; [Figure 15] FIG. 10 is a schematic diagram of a start code block of a second cell according to an embodiment of the present application; [Figure 16] FIG. 10 is a schematic diagram of a start code block of a second cell according to another embodiment of the present application; [Figure 17] FIG. 10 is a schematic diagram of a start code block of a second cell that bears a fragment sequence number according to one embodiment of the present application; [Figure 18] FIG. 10 is a schematic diagram illustrating a case where the start code block of a second cell bears a fragment sequence number according to an embodiment of the present application. [Figure 19] FIG. 10 is a schematic diagram of the field contents of the first coded fragment information whose transmission has been interrupted according to one embodiment of the present application. [Figure 20] FIG. 10 is a schematic diagram of the field contents of subsequent coded fragment information whose transmission has been interrupted according to one embodiment of the present application; [Figure 21] 4 is a flowchart of a method for processing traffic information according to another embodiment of the present application; [Figure 22] 1 is a structural schematic diagram of a cell start code block that does not include traffic type information according to an embodiment of the present application; [Figure 23] FIG. 2 is a schematic diagram of a cell structure according to another example of the present application. [Figure 24] 1 is a schematic diagram of normal Ethernet traffic information carried in the payload area according to an example of the present application; [Figure 25] 22 is a flowchart of the method of step S420 of FIG. 21. [Figure 26] 22 is a flowchart of the method of step S430 of FIG. 21. [Figure 27] 4 is a flowchart of a method for processing traffic information according to another embodiment of the present application; [Figure 28] 28 is a flowchart of the method of step S740 of FIG. 27. [Figure 29] FIG. 1 is a schematic diagram of a network device according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0010] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in detail below with reference to the drawings and examples. The examples described herein are for illustrating the present application, but are not for limiting the present application.

[0011] It should be noted that while a flow chart depicts a logical order, in some cases the steps depicted or described may be performed in an order different from that depicted in the flow chart. In the specification and claims, as well as the description of the drawings, plural (or plural) means two or more, and terms such as "greater than," "less than," and "exceed" are understood to be exclusive of the number, and terms such as "greater than," "less than," and "within" are understood to be inclusive. References such as "first," "second," etc., are for the purpose of distinguishing technical features only and should not be understood as indicating or implying relative importance, or the number of technical features shown, or the context of the technical features shown.

[0012] An embodiment of the present application includes the steps of mapping first traffic information to a first cell and transmitting the first cell, and locating second traffic information at the location of the second cell and transmitting the second traffic information at the location of the second cell. That is, by locating the second traffic information at the location of the second cell and directly transmitting the second traffic information at the location of the second cell, the mapping step of mapping the second traffic information within a cell and carrying it as a bearer can be omitted, thereby simplifying the mapping step and improving not only bearer efficiency but also bandwidth utilization rate.

[0013] In addition, in a communication network, changes in information content also change the structure of the communication network. Traditionally, communication content is mainly voice traffic, and voice traffic is constant bit rate (CBR) traffic, and CBR traffic is high quality of service traffic. High quality of service traffic is traffic information that requires exclusive use of a bearer pipeline that can provide low delay, low jitter, and high reliability bearer service. Here, low delay refers to a delay less than a preset delay value, low jitter refers to a jitter value less than a preset jitter value, and high reliability means that the quality of service (QoS) of various traffic priorities can be ensured. In addition, the preset delay value and the preset jitter value may be set according to actual conditions. In addition, Synchronous Digital Hierarchy (SDH) networks and optical transport network (OTN) bearer networks can provide dedicated bearer pipelines for transmitting voice traffic, so that this voice traffic can be bearered in communication networks based on SDH technology and OTN technology, which largely meets the bearer demand of voice traffic, but the bearer cost of the dedicated bearer pipeline is relatively high.

[0014] With the development of communication technology, the main bearer content in current communication networks is message traffic with an Ethernet structure, and communication network technology is also converting to Ethernet technology. Ethernet technology adopts a statistical multiplexing method and transmits client traffic in a shared manner, that is, all client traffic shares the same bearer pipeline in a statistical multiplexing method, and this bearer pipeline carries the client traffic in a best-effort manner. Therefore, the shared multiplexing method of Ethernet technology can save the utilization rate of the bearer pipeline, improve bearer efficiency, and reduce bearer costs, but the service quality is low.

[0015] Most Ethernet traffic is normal traffic, i.e., normal Ethernet traffic, which has very low requirements for bearer quality but requires high bearer efficiency and low bearer cost. Therefore, how to achieve a shared bearer for high-quality service traffic and normal Ethernet traffic while meeting the bearer quality requirements of high-quality service traffic has become an urgent issue that needs to be resolved.

[0016] In the related art, cells are isolated from each other and do not affect each other. Therefore, when high-quality-of-service traffic is transmitted in some cells and normal Ethernet traffic is transmitted in other cells, the high-quality-of-service traffic and the normal Ethernet traffic are isolated from each other and do not affect each other, so that the high-quality-of-service traffic and the normal Ethernet traffic can be transmitted together in one physical pipeline.

[0017] As shown in FIG. 1, when ordinary Ethernet traffic is transmitted at a rate of 10G or higher (e.g., 25G, 50G, 100G, 200G, 400G, etc.), the ordinary Ethernet traffic must undergo 64B / 66B encoding before transmission. That is, first, 8 bytes (i.e., 64 bits) of data information are extracted from the packet, a 2-bit synchronization header is added before the 64 bits of data information, the 64-bit information code block is expanded to a 66-bit information code block, the 66-bit information code block is then converted into a bit stream (or byte), and mapped into the payload area of a cell for carrying the bearer. Finally, the cell is transmitted. Upon receiving the data stream, the receiving side identifies the 66-bit information code block from the data stream, restores the original 64 bits of data information from the information code block, and then reassembles the 64-bit data information into the original packet. The code block is simply called a block, for example, a 66-bit code block is simply called a 66-bit block, and is not particularly limited here. On the other hand, traffic with a high quality of service (eg, CBR traffic) is directly mapped to the first cell and only needs to be transmitted via the first cell.

[0018] For normal Ethernet traffic, only 64-bit positions in the data code block of one cell can bear normal Ethernet traffic. Therefore, the encoded normal Ethernet traffic information (i.e., 66-bit code blocks) must be carried in the data code blocks of two cells. Furthermore, the 66-bit code blocks corresponding to normal Ethernet traffic must be carried in the data code blocks of the cells using a mapping scheme, which introduces complexity into the process of converting the bit code blocks into bit streams or bytes. Furthermore, the bearer efficiency of cells is limited, and the smaller the cell, the lower the bearer efficiency. Therefore, carrying normal Ethernet traffic in cells using a mapping scheme results in wasted bandwidth. Therefore, how to reduce the mapping complexity introduced when normal Ethernet traffic information is carried through cells and improve the bearer efficiency of normal Ethernet traffic information is an urgent issue that needs to be addressed.

[0019] In all the following embodiments, the start code block of a packet is represented by S', the end code block of a packet by T', the start code block of a fragment by S'', the end code block of a fragment by T'', the start code block of a cell by S''', the end code block of a cell by T''', the data code block of a packet by D', and the fragment data code block by D''.

[0020] Based on the above analysis, examples of the present invention will be described below with reference to the drawings.

[0021] FIG. 2 is a flowchart of a method for processing traffic information according to an embodiment of the present application, which may include, but is not limited to, step S110 and step S120.

[0022] Step S110: Map the first traffic information to a first cell, and transmit the first cell.

[0023] Step S120: Locate the second traffic information at the location of the second cell, and transmit the second traffic information at the location of the second cell.

[0024] The position of the first cell in the cell stream is different from the position of the second cell in the cell stream.

[0025] In one possible embodiment, the first traffic information may be high-quality traffic information such as CBR traffic, high-quality Ethernet traffic information (e.g., Ethernet Common Public Radio Interface (eCPRI) traffic information), voice traffic information, video traffic information, and game traffic information. The high-quality traffic information may be encapsulated in various formats such as an eCPRI protocol message format or an Ethernet message format, and the first traffic information may be normal Ethernet traffic information. The second traffic information may be normal Ethernet traffic information such as download traffic information, or may be high-quality traffic information, and is not particularly limited here.

[0026] In one embodiment, as shown in FIG. 3, assuming that the first traffic information is eCPRI traffic information, the eCPRI traffic information may be 64B / 66B encoded, and the encoded 66-bit code block may be converted into a bit stream or bytes, which may be mapped to the first cell for bearer, but this is not particularly limited.

[0027] In one possible embodiment, the first cell or the second cell may be carried on an Ethernet interface, a Flexible Ethernet (FlexE) time slot, or any other physical or logical interface capable of carrying cells, and is not particularly limited herein.

[0028] Because the content transmitted over the Ethernet interface is a 66-bit code block, the first cell carrying the first traffic information and the second cell carrying the second traffic information are also composed of 66-bit blocks, allowing the cells to be directly transmitted and received over the Ethernet interface. The first two bits of the 66-bit code block defined by the 64B / 66B encoding rule are the synchronization header of the code block. The two synchronization header bits are fixed to either "01" or "10." "01" indicates that the 66-bit code block is a data code block (also called a D code block or D block) containing 8 bytes (i.e., 64 bits) of digital information. "10" indicates that the 66-bit code block is a control code block (abbreviated as a control block). The first byte immediately following the synchronization header indicates the type of control code block, and the following seven bytes contain the content of the control code block (e.g., data information, control information, or data information and control information). The content of these seven bytes is determined by the type of control code block. The control code blocks further include a start code block (also called an S block), an end code block (also called a T block), an idle code block, and a fault maintenance code block, where the start code block is a start flag for one data code block, and the end code block is an end flag for one data code block. In the Ethernet 802.3 standard, the end code blocks are classified into eight types: T0, T1, T2, T3, T4, T5, T6, and T7. T0 has a first byte of 0x87 and does not carry at least one of an overhead field, an indication information indicating an ordering relationship between cells, traffic type information, or fault indication information. T1 has a first byte of 0x99 and carries at least one of a one-byte overhead field, an indication information indicating an ordering relationship between cells, traffic type information, or fault indication information.T2 has a first byte content of 0x99 and bears at least one of a 2-byte overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. Similarly, T7 has a first byte content of 0x99 and bears at least one of a 7-byte overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information.

[0029] In one possible embodiment, the cell structures of the first cell and the second cell are each formed by sequentially assembling a plurality of 66-bit code blocks defined by the 64B / 66B encoding rule, namely, a cell start code block, a cell data code block, and a cell end code block. Here, the cell data code block is a positive integer n, and bears at least one of an overhead field, an indication information indicating an order relationship between cells, traffic type information, or fault indication information. The cell start code block is a cell start flag, and the cell end code block is a cell end flag. As shown in Figure 4, S'" represents the cell start code block, D'" represents the cell data code block, and T'" represents the cell end code block. Since the cell start code block is also a 66-bit code block, the last 7 bytes of the cell start code block may bear at least one of an overhead field, an indication information indicating an order relationship between cells, traffic type information, or fault indication information. Similarly, the last few bytes of the end code block may also bear at least one of an overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. For example, the last seven bytes of T7 may bear at least one of a 7-byte overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. As shown in FIG. 5, each unfilled cell represents a byte position that can be used to fill at least one of an overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. Also, as shown in FIG. 6, both the first cell and the second cell include sequence numbers 1, 2, ..., X (X is a positive integer), and these sequence numbers cyclically appear from 1 to X. These sequence numbers may be used to determine the position of each cell, but are not particularly limited here.

[0030] In this embodiment, a traffic information processing method including the above steps S110 to S120 is adopted. Specifically, the first traffic information is mapped to a first cell and transmitted from the first cell. The second traffic information is located at the position of a second cell and transmitted from the second cell, where the position of the first cell in the cell stream is different from the position of the second cell. That is, the second traffic information is located at the position of the second cell and the second traffic information at the position of the second cell is directly transmitted, thereby omitting the mapping step of mapping the second traffic information into a cell and carrying it as a bearer. Therefore, the mapping step can be simplified, and not only the bearer efficiency can be improved, but also the bandwidth utilization rate can be improved.

[0031] In one embodiment, as shown in FIG. 7, step S120 is described, but step S120 may include, but is not limited to, step S210 and step S220.

[0032] Step S210: Fragment and encode the second traffic information to obtain a plurality of encoded fragment information.

[0033] In one possible embodiment, the encoded fragment information includes a fragment start code block, a fragment data code block, and a fragment end code block.

[0034] Step S220: Each piece of coded fragment information is placed at the position of each second cell.

[0035] In one possible embodiment, there may be only one second cell in one cell cycle. Alternatively, one cell cycle may include multiple second cells with different sequence numbers. For example, one cell cycle may include a second cell with sequence number 1, a second cell with sequence number 2, ..., a second cell with sequence number X, where X is a positive integer. Alternatively, different cell cycles may include second cells with the same sequence number. For example, the first cell cycle may include a second cell with sequence number 1 and a second cell with sequence number 2, and the second cell cycle may also include a second cell with sequence number 1 and a second cell with sequence number 2, but this is not particularly limited here.

[0036] In one possible embodiment, the length of the encoded fragment information may be the same as the length of the second cell, so that after each encoded fragment information is placed in the position of each second cell, the fragment start code block of each encoded fragment information is placed in the position of the start code block of each second cell, and the fragment end code block of each encoded fragment information is placed in the position of the end code block of each second cell. In some embodiments, as shown in Figure 8, assuming that the length of the second cell is 7 code blocks and the second traffic information is a client message including four packets, packet1, packet2, packet3, and packet4, when 64B / 66B encoding each packet of this client message, the client message may be fragmented so that each encoded fragment information is 7 code blocks long to obtain multiple pieces of encoded fragment information, and then each piece of encoded fragment information with a length of 7 code blocks may be placed in the position of each second cell, but this is not particularly limited here.

[0037] In one possible embodiment, the length of at least two adjacent pieces of coded fragment information among the plurality of pieces of coded fragment information is not equal to the length of the second cell, and the sum of the lengths of the at least two adjacent pieces of coded fragment information is equal to an integer multiple of the length of the second cell, thereby reducing at least one pair of pseudo end code blocks and pseudo start code blocks and improving bearer efficiency. After each piece of coded fragment information is located at the position of each second cell, the fragment start code block of each piece of coded fragment information is located at the position of the start code block of each second cell, and the fragment end code block of each piece of coded fragment information is located at the end code block of each second cell. The fragment start code block and the fragment end code block belong to different pieces of coded fragment information. For example, assuming the length of the second cell is 7 code blocks, the second traffic information may be fragment-coded into one piece of coded fragment information with a length of 3 code blocks, one piece of coded fragment information with a length of 4 code blocks, and multiple pieces of coded fragment information with a length of 7 code blocks. Alternatively, as shown in Figure 9, this second traffic information may be fragment-coded into one piece of coded fragment information having a length of 8 code blocks (i.e., third coded fragment information), one piece of coded fragment information having a length of 6 code blocks (i.e., fourth coded fragment information), and a plurality of pieces of coded fragment information having a length of 7 code blocks (e.g., first coded fragment information, second coded fragment information, and fifth coded fragment information). Alternatively, this second traffic information may be fragment-coded into one piece of coded fragment information having a length of 2 code blocks, one piece of coded fragment information having a length of 5 code blocks, and a plurality of pieces of coded fragment information having a length of 7 code blocks, etc., but this is not particularly limited here.

[0038] In one possible embodiment, when each piece of encoded fragment information is completed, the encoded fragment information can be directly placed at the location of the second cell, and the second traffic information at the location of the second cell can be transmitted; that is, the second traffic information can be transmitted at the location of the second cell while being fragmented and encoded. After all the encoded fragment information is completed, it is not necessary to place them together at the corresponding location of the second cell, nor is it necessary to transmit all the second traffic information together after all the encoded fragment information is placed in the second cell.

[0039] In this embodiment, by adopting the traffic information processing method including the above steps S210 to S220, the second traffic information can be fragmented and encoded to obtain multiple pieces of encoded fragment information, and then each piece of encoded fragment information can be placed at the location of each second cell. Therefore, in the embodiment of the present application, the fragment encoding method is adopted to generate a sequence code block from the client message, and the sequence code block can be directly sent at the cell location, thereby solving the problems of complexity caused by bearing the code block of the client message to the cell using the mapping method and the low cell bearer efficiency.

[0040] In another embodiment, the second traffic information may be located at the position of the second cell, and the second traffic information may be encoded when the second traffic information is located. Therefore, in this embodiment, it is not necessary to fragment the second traffic information. For example, assuming that the second traffic information includes one packet, if the first encoded code block of the packet is the start code block of the packet, the start code block of the packet may be located at the position of the start code block of the second cell. If the first encoded code block of the packet is the data code block of the packet, the data code block of the packet may be located at the position of the data code block of the second cell, or a pseudo start code block may be located at the position of the start code block of the second cell, but this embodiment is not particularly limited thereto.

[0041] Based on the above-described embodiments, when placing the second traffic information at the position of the second cell, if the cell stream includes at least two adjacent second cells, the at least two adjacent second cells are treated as one target cell, and the second traffic information is placed at the position of the target cell. In some embodiments, a pseudo start code block or a true start code block is placed at the position of the start code block of each second cell among the target cells, a pseudo end code block or a true end code block is placed at the position of the end code block of each second cell, and the second traffic information is placed between the start code block and the end code block of each second cell. Here, the true start code block indicates that the start code block is the start code block of the packet and not the start code block of the second cell, the true end code block indicates that the end code block is the end code block of the packet and not the end code block of the second cell, the pseudo start code block indicates that the start code block is the start code block of the second cell and not the start code block of the packet, and the pseudo end code block indicates that the end code block is the end code block of the second cell and not the end code block of the packet.

[0042] In one possible embodiment, the true start code block is placed at the position of the start code block of the first second cell among the target cells, the pseudo start code block is placed at the position of the start code block of a cell other than the first second cell among the target cells, the true end code block is placed at the position of the end code block of the last second cell among the target cells, and the pseudo end code block is placed at the position of the end code block of a cell other than the last second cell among the target cells, but this is not particularly limited here.

[0043] In one embodiment, as shown in FIG. 10, when the second traffic information includes at least one packet, step S210 is described, which may include, but is not limited to, step S310 and step S320.

[0044] Step S310: Each packet is fragmented and encoded to obtain a plurality of encoded code blocks.

[0045] In one possible embodiment, a packet may be 64B / 66B encoded. When encoding a packet using 64B / 66B, the preamble and frame gap portion of the packet may be encoded as a start code block, the data portion in the middle of the packet may be encoded as a data code block, and another portion at the end of the data portion of the packet may be encoded as an end code block. Therefore, the encoded code blocks of a packet may be divided into a start code block, a data code block, and an end code block, but this is not particularly limited thereto.

[0046] Step S320: Assemble a plurality of encoded code blocks according to a preset rule to obtain a plurality of encoded fragment information.

[0047] In one possible embodiment, the pre-set rule may include at least one of the following: the same encoded fragment information includes encoded code blocks of the same packet; the same encoded fragment information includes encoded code blocks of multiple packets; the same encoded fragment information includes a target code block assembly block and an encoded code block of a packet; and the same encoded fragment information includes a target code block assembly block, but is not particularly limited thereto.

[0048] In one embodiment, the preset rules include that the same encoded fragment information includes encoded code blocks of multiple packets and that the same encoded fragment information includes encoded code blocks of the same packet. If the sum of the lengths of the multiple encoded code blocks corresponding to the same target packet is smaller than the length of the encoded fragment information, the multiple encoded code blocks of the target packet and the encoded code blocks of the target packet's adjacent packets are assembled into the same encoded fragment information. Here, the same encoded fragment information includes the start code block of the target packet and the end code block of the adjacent packet, or the end code block of the target packet and the start code block of the adjacent packet. If the sum of the lengths of the multiple encoded code blocks corresponding to the same target packet is greater than the length of the encoded fragment information, the multiple encoded code blocks of the same packet may be assembled into the same encoded fragment information, but this is not particularly limited.

[0049] In some embodiments, as shown in FIG. 8 , assume that each piece of encoded fragment information is seven code blocks long and the second traffic information includes five packets: packet1, packet2, packet3, and packet4. When packet1 is fragmented and encoded, five encoded code blocks are obtained. Of these, the first encoded code block is the start code block S' of packet1, but is also the fragment start code block S'' of the first piece of encoded fragment information. The fifth encoded code block is the end code block T' of packet1. In this case, packet1 is the target packet, packet2 is the adjacent packet, and the start code block S' of packet1 is also the start code block S' of the target packet. Because the sum of the lengths of the five encoded code blocks of packet1 is less than the length of the encoded fragment information, fragment encoding of packet2 continues to obtain the start code block S' of packet2. Packet2 is then fragmented and encoded to obtain the seventh encoded code block. This encoded code block can be designated as the fragment end code block T''. Finally, the seven resulting encoded code blocks are assembled to obtain the first piece of encoded fragment information. The first encoded fragment information bears both the start code block S' and end code block T' of packet1 and the start code block S' of packet2.

[0050] After obtaining the first encoded fragment information, the encoded fragment information may be directly placed in the position of the corresponding second cell, the fragment start code block of the encoded fragment information may be placed in the position of the start code block of the second cell, and the fragment end code block of the encoded fragment information may be placed in the position of the end code block of the second cell, and the second traffic information may be transmitted in the position of the second cell. Next, assembly of the second encoded fragment information may continue. First, the remaining portion of packet2 may be fragmented and encoded to obtain one encoded code block, which may be designated as the fragment start code block S'' of the second encoded fragment information (this encoded code block is not the start code block S' of packet2). Packet2 may then be fragmented and encoded to obtain five encoded code blocks, which may be designated as the fragment data code block D''. Finally, packet2 may be fragmented and encoded to obtain the seventh encoded code block, which may be designated as the fragment end code block T''. Finally, the seven resulting encoded code blocks may be assembled to obtain the second encoded fragment information.

[0051] Similarly, after obtaining the second piece of encoded fragment information, the encoded fragment information is directly placed in the position of the corresponding second cell, the fragment start code block of the encoded fragment information is placed in the position of the start code block of the second cell, and the fragment end code block of the encoded fragment information is placed in the position of the end code block of the second cell, and the second traffic information at the position of the second cell is transmitted. Next, the assembly of the third piece of encoded fragment information continues. Because packet2 has not yet completed fragment encoding, fragment encoding of packet2 continues, obtaining one encoded code block, and this encoded code block is set as the fragment start code block S'' of the third piece of encoded fragment information (this encoded code block is not the start code block S' of packet2). Packet2 is then fragmented and encoded, and one end code block is sequentially obtained. Here, this end code block is not the fragment end code block T'' of the third piece of encoded fragment information, but the end code block T' of packet2, at which point fragment encoding of packet2 is complete. At this point, the sum of the lengths of the two encoded code blocks obtained by fragment encoding is smaller than the length of the third piece of encoded fragment information, so packet3 needs to be fragmented and encoded. First, packet3 is fragmented and coded to obtain the first coded code block, which is not the fragment start code block S'' of the third coded fragment information, but the start code block S' of packet3. Next, packet3 is fragmented and coded to obtain three coded code blocks in turn, which all become fragment data code blocks D'' of the third coded fragment information. Finally, packet3 is fragmented and coded to obtain the seventh coded code block, which becomes the fragment end code block T'' of the third coded fragment information (this T block is not the end code block T' of packet3).Finally, the seven obtained encoded code blocks are assembled to obtain the third encoded fragment information.

[0052] Similarly, after obtaining the third encoded fragment information, this encoded fragment information can be directly placed in the position of the corresponding second cell, the fragment start code block of this encoded fragment information can be placed in the position of the start code block of the second cell, and the fragment end code block of this encoded fragment information can be placed in the position of the end code block of the second cell, and second traffic information at the position of this second cell can be transmitted. After obtaining the third encoded fragment information by assembly, fragment encoding of packet3 is not yet complete, so fragment encoding of packet3 continues, obtaining one encoded code block, and this encoded code block is designated as the fragment start code block S'' of the fourth encoded fragment information rather than the start code block S' of packet3. Next, packet3 is fragmented and encoded to obtain the final encoded code block, which is the end code block T' of packet3 rather than the fragment end code block T'' of the fourth encoded fragment information, and fragment encoding of packet3 is now complete. At this point, the sum of the lengths of the two encoded code blocks obtained by fragment encoding is smaller than the length of the fourth encoded fragment information, so packet4 needs to be fragmented and encoded. In this way, the fourth encoded fragment information is obtained, and therefore a description thereof will be omitted here.

[0053] In one possible embodiment, the fragment end code block T'' of all the encoded fragment information in the above example may be 0, 1, 2, 6, or 7 bytes, etc. When the byte of T'' is 0, T'' is T0, and T0 does not carry any content in the packet. When the byte of T'' is 1, T'' is T1. When the byte of T'' is 6, T'' is T6. When the byte of T'' is 7, T'' is T7. However, this is not particularly limited. Furthermore, after each piece of encoded fragment information is completed, it may be directly placed in the position of a second cell, its fragment start code block in the position of the start code block of the second cell, and its fragment end code block in the position of the end code block of the second cell, and the second traffic information at the position of this second cell may be transmitted. After all the encoded fragment information is completed, it is not necessary to place them together in the positions of the corresponding second cells, and after all the encoded fragment information is placed in the positions of the second cells, it is not necessary to transmit the second traffic information at the position of the second cells together.

[0054] In one possible embodiment, when placing the encoded fragment information at the position of the second cell, the pseudo start code block or the start code block of the target packet may be placed at the position of the start code block of the second cell, and the pseudo end code block or the end code block of the target packet may be placed at the position of the end code block of the second cell, but this is not particularly limited here.

[0055] In one embodiment, assuming that the length of the target encoded fragment information is 7 code blocks and the second traffic information includes one packet, i.e., packet1, if packet1 is fragmented and encoded to obtain five encoded code blocks, the first encoded code block being the start code block S' of packet1 and the fifth encoded code block being the end code block T' of packet1, the pseudo start code block may be set to the fragment start code block S'' and the pseudo end code block may be set to the fragment end code block T'', and the pseudo start code block, the five encoded code blocks obtained by fragmenting and encoding packet1, and the pseudo end code block may be sequentially assembled to form the encoded fragment information. Alternatively, assuming that the length of the target encoded fragment information is seven code blocks and the second traffic information includes one packet, i.e., packet1, fragmenting and encoding packet1 to obtain six encoded code blocks, the first encoded code block being the start code block S' of packet1 and the sixth encoded code block being the end code block T' of packet1, the pseudo start code block can be placed at the position of the fragment start code block S'' and the end code block T' of packet1 can be placed at the position of the fragment end code block T'', and the pseudo start code block and the six encoded code blocks obtained by fragmenting and encoding packet1 can be sequentially assembled to form encoded fragment information, but this is not particularly limited here.

[0056] In one possible embodiment, between at least two adjacent pieces of encoded fragment information, the former piece of encoded fragment information does not set a fragment end code block, and the latter piece of encoded fragment information does not set a fragment start code block.

[0057] In one embodiment, assuming that the length of the first encoded fragment information and the length of the second encoded fragment information are both seven code blocks and the second traffic information includes two packets, packet1 and packet2, fragmenting and encoding packet1 results in nine encoded code blocks, where the first encoded code block is the start code block S' of packet1 and the ninth encoded code block is the end code block T' of packet1. Fragmenting and encoding packet2 results in five encoded code blocks, where the first encoded code block is the start code block S' of packet2 and the fifth encoded code block is the end code block T' of packet2. The first seven encoded code blocks of packet1 are sequentially assembled to obtain the first encoded fragment information, and the seventh code block is the data code block of packet1. Therefore, this first encoded fragment information does not include the fragment end code block T'. The last two encoded code blocks of packet1 and the five encoded code blocks of packet2 constitute the second encoded fragment information. In this way, the start code block S' of packet 1 is beared in the fragment start code block S'' of the first encoded fragment information, the seventh encoded code block of packet 1 is placed in the position of the last code block of the first encoded fragment information, the eighth encoded code block of packet 1 is placed in the position of the first code block of the second encoded fragment information, and the end code block T' of packet 1 is beared in the position of the second code block of the second encoded fragment information, and therefore the second encoded fragment information does not include the fragment start code block S''.Similarly, the start code block S' of packet2 is placed at the position of the third code block of the second encoded fragment information, and thus the end code block T' of packet2 is placed at the position of the last code block of the second encoded fragment information, and therefore the second encoded fragment information does not include a fragment end code block T'', although this is not particularly limited here.

[0058] In the scenario of transmitting a second cell while fragmenting and encoding second traffic information based on the above embodiment, the first encoded fragment information, in which a fragment start code block S''' is placed at the start code block S''' of the first second cell among the cell positions, does not have a fragment end code block T''', so when the first encoded fragment information is placed at the position of the second cell, there is no end code block T'''. Next, fragment encoding of packets 1 and 2 of the second traffic information is continued to obtain seven encoded code blocks, and these seven encoded code blocks are assembled into second encoded fragment information. Therefore, this second encoded fragment information does not include a fragment start code block S''. Then, this second encoded fragment information is placed at the position of the next second cell. Therefore, there is no cell start code block S''' at the position of the first code block of the next second cell. Therefore, in this embodiment, by adopting this method, when an adjacent second cell is taken as one target cell, the cell's start code block S''' is always placed at the position of the first code block of the former cell (i.e., the first code block of the target cell), and the cell's end code block T''' is always placed at the position of the last code block of the latter cell position (i.e., the last code block of the target cell); and among the adjacent cells, the cell's end code block T''' is not placed at the position of the last code block of the former cell position, and the cell's start code block S''' is not placed at the position of the first code block of the latter cell position.

[0059] In one embodiment, as shown in Figures 11 and 8, assuming that the first traffic information is high-quality service traffic information and the second traffic information is normal Ethernet traffic information, the high-quality service traffic information is mapped to three first cells, and the normal Ethernet traffic information is fragmented and encoded to obtain three pieces of encoded fragment information. Then, the three pieces of encoded fragment information are placed at the positions of three second cells. Here, the first cell is located between the first second cell (i.e., cell 2) and the second second cell (i.e., cell 4), and the second second cell (i.e., cell 4) and the third second cell (i.e., cell 5) are adjacent to each other. Therefore, the encoded fragment information carried by the second second cell (i.e., the second encoded fragment information) and the encoded fragment information carried by the third second cell (i.e., the third encoded fragment information) are adjacent to each other. Therefore, the fragment end code block of the second encoded fragment information and the fragment start code block of the third encoded fragment information are adjacent to each other (or the end code block of the second second cell and the start code block of the third second cell are adjacent to each other). Furthermore, the fragment end code block of the second encoded fragment information is not the end code block of packet2, and the fragment start code block of the third encoded fragment information is not the start code block of packet2. That is, neither the fragment end code block of the second encoded fragment information nor the fragment start code block of the third encoded fragment information bears normal Ethernet traffic information, resulting in reduced bearer efficiency. Based on this, if the sum of the lengths of multiple encoded code blocks corresponding to the same target packet is greater than the length of the encoded fragment information, the fragment start code blocks and fragment end code blocks between at least two adjacent target encoded fragment information can be canceled, thereby improving bearer efficiency and facilitating the receiving side's restoration of the second traffic information.

[0060] Based on the above embodiment, as shown in FIG. 12, one data code block D' of packet2 is placed at the position of the last code block of the second encoded fragment information, and another data code block D' of packet2 is placed at the position of the first code block of the third encoded fragment information. Because the fragment end code block of the second encoded fragment information and the fragment start code block of the third encoded fragment information both bear normal Ethernet traffic information, this embodiment improves bearer efficiency. Furthermore, when the receiving side receives the second second cell corresponding to the second encoded fragment information and the third second cell corresponding to the third encoded fragment information, it does not need to determine whether the end code block of the second second cell is a pseudo end code block, nor does it need to determine whether the start code block of the third second cell is a pseudo start code block, thereby speeding up the receiving side's restoration of normal Ethernet traffic information.

[0061] In one embodiment, the preset rule includes that the same encoded fragment information includes a target code block assembly block and an encoded code block of the packet, where the target code block assembly block includes at least one of an idle code block, a pseudo start code block, or a pseudo end code block. If the sum of the lengths of the encoded code blocks corresponding to the same target packet is greater than the length of the encoded fragment information, or if the sum of the lengths of the encoded code blocks corresponding to the same target packet is less than the length of the encoded fragment information, the encoded code blocks of the target packet and the target code block assembly block are assembled into the same encoded fragment information, where the target code block assembly block may be at least one of an idle code block, a pseudo start code block, or a pseudo end code block. For example, the target encoded fragment information may use the pseudo start code block as the fragment start code block and the end code block of the target packet as the fragment end code block. Alternatively, the target encoded fragment information may use the start code block of the target packet as the fragment start code block and the pseudo end code block as the fragment end code block. Alternatively, the target encoded fragment information may use a pseudo start code block as the fragment start code block and a pseudo end code block as the fragment end code block. Alternatively, the target encoded fragment information may use an idle code block as the fragment start code block and the end code block of the target packet as the fragment end code block, but this is not particularly limited. An idle code block is a control code block obtained by 64B / 66B encoding of normal Ethernet traffic information, and is also called an idle code block or an I code block.

[0062] In one embodiment, if the length of the encoded code block obtained by fragmenting and encoding the target packet is one code block less than the length of the encoded fragment information, one pseudo-end code block is used as the fragment end code block T'' of the encoded fragment information, and the encoded code block obtained by fragmenting and encoding the target packet and the pseudo-end code block are assembled to form the same encoded fragment information.

[0063] In another embodiment, if the length of the encoded code block obtained by fragmenting and encoding the target packet is smaller than the length of the encoded fragment information, the idle code block and the encoded code block obtained by fragment encoding may be assembled into the same encoded fragment information, thereby ensuring that the length of each encoded fragment information is constant. Here, this idle code block may be carried at any position in the encoded fragment information, such as the fragment start code block S'' of the encoded fragment information, the code block position between the fragment start code block and the fragment end code block, or the fragment end code block T'' of the encoded fragment information.

[0064] In another embodiment, the preset rule includes a condition that the same encoded fragment information includes a target code block assembly block. Here, the target code block assembly block includes at least one of an idle code block, a pseudo start code block, or a pseudo end code block. As shown in Configuration 1 of FIG. 13, when there is no target packet, multiple idle code blocks I may be directly assembled into encoded fragment information. Alternatively, as shown in Configuration 2 of FIG. 13, the first two code blocks of the encoded fragment information may be sequentially filled with a pseudo start code block S'''' and a pseudo end code block T'''', an idle code block I may be carried in an intermediate code block of the encoded fragment information, and the last two code blocks of the encoded fragment information may be sequentially filled with a pseudo start code block S'''' and a pseudo end code block T''''. Alternatively, as shown in Configuration 3 of FIG. 13, the code blocks of the encoded fragment information may be alternately filled with a pseudo start code block S'''' and a pseudo end code block T''''.

[0065] In this embodiment, by adopting the traffic information processing method including the above steps S310 to S320, when the second traffic information includes at least one packet, each packet may be fragmented and encoded to obtain a plurality of encoded code blocks, and then the plurality of encoded code blocks may be assembled according to a predetermined rule to obtain a plurality of encoded fragment information. Therefore, in this embodiment, the length of the encoded fragment information obtained by assembling the encoded code blocks obtained by fragmenting and encoding a packet can be matched with the length of the second cell according to the predetermined rule, which makes it easy to directly place the encoded fragment information at the position of the second cell in a subsequent step.

[0066] In one embodiment, the encoded fragment information includes a fragment end code block and a fragment start code block, where the fragment end code block may be a true end code block or a pseudo end code block, where the true end code block refers to the end code block of each packet in the second traffic information, and the pseudo end code block is not the end code block of each packet in the second traffic information. The fragment start code block may be a true start code block or a pseudo start code block, where the true start code block refers to the start code block of each packet in the second traffic information, and the pseudo start code block is not the start code block of each packet in the second traffic information. As shown in Figure 8, the fragment start code block S'' indicated by an arrow is a pseudo start code block, and the fragment end code block T'' indicated by an arrow is a pseudo end code block.

[0067] A pseudo end code block in one piece of encoded fragment information and a pseudo start code block in the next piece of encoded fragment information appear as a pair. If the fragment end code block in one piece of encoded fragment information is a pseudo end code block, it indicates that the second traffic information has been truncated by this pseudo end code block, and the fragment start code block in the next piece of encoded fragment information is necessarily a pseudo start code block. Conversely, if the fragment start code block in one piece of encoded fragment information is a pseudo start code block, it indicates that the second traffic information has been truncated, so the fragment end code block in the immediately preceding piece of encoded fragment information is necessarily a pseudo end code block, and the immediately preceding piece of encoded fragment information contains part of this second traffic information. Therefore, simply by identifying whether the fragment start code block is a pseudo start code block, it is possible to reverse-derive whether the immediately preceding fragment end code block is a pseudo end code block, and there is no need to mark whether the fragment end code block is a pseudo end code block.

[0068] Furthermore, if the second traffic information is normal Ethernet traffic information, when the normal Ethernet traffic information is fragmented and encoded, the format of the start code block of this normal Ethernet traffic information (i.e., the start code block S' of the packet) is generally fixed, as shown in FIG. 14. In FIG. 14, the bit value of the synchronization header of the start code block is "10," the content of the first byte immediately after the synchronization header is "0x78," which indicates the type of control block, and then six bytes of "0x55" and one byte of "0xd5," where the six bytes of "0x55" are interframe bytes of the Ethernet message and the one byte of "0xd5" is the frame delimiter of the Ethernet message. Since the interframe bytes and the frame delimiter are fixed contents in the encoded code block of normal Ethernet traffic information, the appearance of six bytes of "0x55" and one byte of "0xd5" in the encoded code block indicates that the traffic information is the start code block of normal Ethernet traffic information (i.e., the start code block S' of the packet).

[0069] Based on this, in one embodiment, the start code block of a packet includes, but is not limited to, a message code block type flag value for determining the type of the start code block of the current packet, the type of the end code block of the immediately preceding packet, and the type of the end code block after the start code block of the current packet.

[0070] In one embodiment, taking the message code block type flag value as an example, when the message code block type flag value is a first preset value, the message code block type flag value indicates that the current start code block is a true start code block and the end code block after the current start code block is a true end code block. The true start code block indicates that the start code block is not the start code block of the second cell but the start code block of the packet, and the true end code block indicates that the end code block is not the end code block of the second cell but the end code block of the packet. For example, as shown in FIG. 16, the first preset value is represented by xxxx. Assume that the first preset value is located at the seventh byte after the synchronization header in the start code block. If the first preset value xxxx is 0x55, this indicates that the current start code block is a true start code block and the end code block after the current start code block is a true end code block. The first preset value may also be located at another byte position or may be another value, but is not particularly limited here.

[0071] In another embodiment, when the message code block type flag value is a second preset value, the message code block type flag value indicates that the current start code block is a true start code block and that the end code block after the current start code block is the end code block of the packet but is the end code block of the second cell. Here, the true start code block indicates that the start code block is not the start code block of the second cell but is the start code block of the packet, and the pseudo end code block indicates that the end code block is not the end code block of the packet but is the end code block of the second cell. For example, as shown in FIG. 16, the second preset value is represented by xxxx. Assume that the second preset value is located at the seventh byte after the synchronization header in the start code block. If the second preset value xxxx is 0x5A, this indicates that the current start code block is a true start code block and that the end code block after the current start code block is the end code block of the packet but is the end code block of the second cell. The second preset value may also be located at another byte position or may be another value, and is not particularly limited herein.

[0072] In one embodiment, the fragment start code block of the encoded fragment information includes a fragment code block type flag value for determining the type of the start code block of the current encoded fragment information, the type of the end code block of the immediately preceding encoded fragment information, and the type of the end code block after the start code block of the current encoded fragment information. Here, the type of the start code block of the current encoded fragment information may be a fragment start code block, the start code block of the packet, or both the fragment start code block and the start code block of the packet. The fragment code block type flag value may also be used to determine the type of the last end code block of the current encoded fragment information. The type of the last end code block of the current encoded fragment information may be a fragment end code block, the end code block of the packet, or both the fragment end code block and the end code block of the packet, and is not particularly limited here. For example, if it is determined that the type of the last end code block of the current encoded fragment information is a fragment end code block rather than a start code block of the packet, it may be determined that the type of the end code block of the immediately preceding encoded fragment information is a fragment end code block rather than a packet end code block. The fragment code block type flag value may be set in any byte from the second byte to the eighth byte after the synchronization header in the start code block, and this fragment code block type flag value may be any value other than 0x55 or 0xd5.For example, if the fragment code block type flag value is "0xAA", it is assumed to be used to indicate that the current start code block is a pseudo start code block, indicating that the start code block is not the start code block of a packet but a fragment start code block (i.e., the start code block of a real message), and that the end code block immediately before the start code block (i.e., the type of the end code block of the immediately preceding encoded fragment information) is a pseudo end code block, where the pseudo end code block indicates that the end code block of the immediately preceding encoded fragment information is a fragment end code block rather than the end code block of a packet.

[0073] 15, when the coded fragment information uses a pseudo start code block as a start code block, i.e., when the start code block is not a packet start code block but a fragment start code block, the fragment code block type flag value may be set to "0xAA" and placed in the seventh byte after the synchronization header of the fragment start code block to generate a fragment start code block and identify the fragment start code block as a pseudo start code block. When a second cell bearing the coded fragment information is received, the fragment start code block may be determined not to be a packet start code block based on the fragment code block type flag value of the fragment start code block corresponding to the start code block of the second cell. Alternatively, the fragment code block type flag value may be set to "0xFF" and placed in the eighth byte after the synchronization header to generate a fragment start code block and identify the fragment start code block as a pseudo start code block, but this is not particularly limited here.

[0074] In one embodiment, the start code block of the second cell includes a cell code block type flag value that is used to determine the type of the start code block of the current second cell, the type of the end code block of the immediately preceding second cell, and the type of the end code block after the start code block of the current second cell.

[0075] In another embodiment, taking the cell code block type flag value as an example, when the cell code block type flag value is a third preset value, the cell code block type flag value indicates that the start code block of the current second cell is the start code block of the packet, but is also the start code block of the second cell, and the end code block after the start code block of the current second cell is a true end code block, where the true end code block indicates that the end code block is not the end code block of the second cell but the end code block of the packet. For example, as shown in Figure 16, the third preset value is represented by xxxx. Assume that the third preset value is located at the seventh byte after the synchronization header in the start code block of the second cell. If the third preset value xxxx is 0xF5, the start code block of the current second cell is the start code block of the second cell, but is also the start code block of the packet (i.e., the start code block of the client message), and the end code block after the current start code block of the second cell is the true end code block, that is, this end code block is not the end code block of the second cell, but the end code block of the packet (i.e., the end code block of the client message). In addition, the third preset value may be located at another byte position or may be another value, and is not particularly limited here.

[0076] In another embodiment, when the cell code block type flag value is a fourth preset value, the cell code block type flag value indicates that the start code block of the current second cell is the start code block of the packet, but is also the start code block of the second cell, and the end code block after the start code block of the current second cell is a pseudo end code block, where the pseudo end code block indicates that the end code block is not the end code block of the packet, but is the end code block of the second cell. For example, as shown in FIG. 16, the fourth preset value is represented by xxxx, and assuming that the fourth preset value is located at the seventh byte after the synchronization header in the start code block of the second cell, when the fourth preset value xxxx is 0xFA, it indicates that the start code block of the current second cell is the start code block of the packet (i.e., the start code block of the client message), and the end code block after the start code block of the current second cell is a pseudo end code block. Furthermore, the fourth preset value may be located at another byte position or may be another value, and is not particularly limited here.

[0077] In another embodiment, when the cell code block type flag value is a fifth preset value, the cell code block type flag value indicates that the start code block of the current second cell is a pseudo start code block and the end code block after the start code block of the current second cell is a true end code block, where the pseudo start code block indicates that the start code block is not the start code block of the packet but the start code block of the second cell, and the true end code block indicates that the end code block is not the end code block of the second cell but the end code block of the packet. For example, as shown in FIG. 16, the fifth preset value is represented by xxxx, and assuming that the fifth preset value is located at the seventh byte after the synchronization header in the start code block of the second cell, when the fifth preset value xxxx is 0xA5, it indicates that the current encoded code block is not the start code block of the packet (i.e., not the start code block of the client message) but the start code block of the second cell, and the end code block after the start code block of the current second cell is a true end code block. Furthermore, the fifth preset value may be at another byte position or may be another value, and is not particularly limited here.

[0078] In another embodiment, when the cell code block type flag value is a sixth preset value, the cell code block type flag value indicates that the start code block of the current second cell is a pseudo start code block and the end code block after the start code block of the current second cell is a pseudo end code block, where the pseudo start code block indicates that the start code block is not the start code block of a packet but the start code block of the second cell, and the pseudo end code block indicates that the end code block is not the end code block of a packet but the end code block of the second cell. For example, as shown in FIG. 16, the sixth preset value is represented by xxxx, and assuming that the sixth preset value is located at the seventh byte after the synchronization header in the start code block of the second cell, when the sixth preset value xxxx is 0xAA, it indicates that the start code block of the current second cell is not the start code block of a client message but is only the start code block of the second cell, and also that the subsequent end code block is not the end code block of a packet (i.e., not the end code block of a client message) but is only the end code block of the second cell. Furthermore, the sixth preset value may also be at another byte position or may be another value, and is not particularly limited here.

[0079] The fragment code block type flag value may be various values, and the meanings indicated by the respective values may be the same as those indicated by the cell code block type flag value in the above embodiment, and therefore, the description thereof will be omitted here.Similarly, the message code block type flag value may be various values, and the meanings indicated by the respective values may be the same as those indicated by the cell code block type flag value in the above embodiment, and therefore, the description thereof will be omitted here.

[0080] In one embodiment, since the pseudo end code block of one second cell and the pseudo start code block of the next second cell appear as a pair, a fragment sequence number may be carried in the start code block of the second cell corresponding to each piece of encoded fragment information to determine whether the current second cell is the second cell in which the last piece of encoded fragment information is placed. If the current second cell is not the second cell in which the last piece of encoded fragment information is placed, it may be determined that the end code block of the second cell in which the encoded fragment information is placed is always a pseudo end code block. On the other hand, if the encoded fragment information placed in the current second cell is the last piece of encoded fragment information, it may be determined that the first end code block immediately after the start code block of the second cell in which the encoded fragment information is placed is always a true end code block. For example, as shown in FIG. 17, the fragment sequence number SQ may be carried in the sixth byte after the synchronization header of the start code block of the second cell, and the fragment sequence numbers SQ corresponding to each successive piece of encoded fragment information may be set so that the fragment sequence numbers gradually decrease. That is, the fragment sequence numbers SQ corresponding to each successive piece of encoded fragment information may be in the order X, X-1, X-2, ..., 2, 1, 0, where X is a natural number and is not particularly limited here.

[0081] 18 , packet2 is fragmented and encoded to obtain four pieces of encoded fragment information, and these four pieces of encoded fragment information are placed in corresponding second cells. Then, second traffic information (e.g., client traffic) is transmitted at the position of the second cell. The fragment start code blocks of these four pieces of encoded fragment information all include fragment sequence numbers SQ, and the fragment sequence numbers SQ corresponding to these four pieces of encoded fragment information are 3, 2, 1, and 0, respectively. The encoded fragment information with fragment sequence numbers SQ 2 and 1 corresponds to the middle encoded code block of packet2. Therefore, it can be determined that the fragment end code blocks in these encoded fragment information with fragment sequence numbers SQ 2 and 1 are pseudo end code blocks. Furthermore, because the encoded fragment information with fragment sequence number SQ 1 is the last encoded fragment information corresponding to packet2, it can be determined that the first end code block immediately after the fragment start code block in this encoded fragment information is the true end code block, which is the end code block T′ of packet2.

[0082] The 802.3br standard for Ethernet defines a method for simultaneously transmitting messages of different priorities, in which a higher-priority message interrupts a lower-priority message. For example, if the priority of second traffic information is lower than that of first traffic information, and the second traffic information is currently being transmitted and the first traffic information needs to be transmitted, the transmission of the second traffic information is interrupted or stopped, and the first traffic information is transmitted first or interrupted. Regarding the encoded fragment information of the second traffic information whose transmission is interrupted, the 802.3br standard specifies a method for indicating each piece of encoded fragment information whose transmission is interrupted, as shown in Figures 19 and 20. In Figure 19, for the first piece of encoded fragment information whose transmission is interrupted, the content of the eighth byte of the fragment start code block of that encoded fragment information may be set to SMD-S. Here, SMD-S may be SMD-S0, SMD-S1, SMD-S2, or SMD-S3, and SMD-S0, SMD-S1, SMD-S2, and SMD-S3 correspond to different values, as shown in Table 1. 20, for other encoded fragment information after the first encoded fragment information, the content of the seventh byte of the fragment start code block of that encoded fragment information may be set to SMD-C, where SMD-C may be any of SMD-C0, SMD-C1, SMD-C2, or SMD-C3, and SMD-C0, SMD-C1, SMD-C2, and SMD-C3 correspond to different values, as shown in Table 1. Furthermore, the SMD-S of the first encoded fragment information must correspond to the SMD-C of other encoded fragment information after the first encoded fragment information; that is, if the fragment start code block of the first encoded fragment information is set to SMD-S0, the fragment start code blocks of the other subsequent encoded fragment information must be set to SMD-C0.If the fragment start code block of the first encoded fragment information is set to SMD-S1, the fragment start code blocks of other subsequent encoded fragment information must be set to SMD-C1. If the fragment start code block of the first encoded fragment information is set to SMD-S2, the fragment start code blocks of other subsequent encoded fragment information must be set to SMD-C2. If the fragment start code block of the first encoded fragment information is set to SMD-S3, the fragment start code blocks of other subsequent encoded fragment information must be set to SMD-C3.

[0083] [Table 1]

[0084] [Table 2]

[0085] Furthermore, the field frag_count, which corresponds to the eighth byte in the fragment start code blocks of other encoded fragment information after the first encoded fragment information, may indicate the order of subsequent encoded fragment information in order to facilitate out-of-order detection. In some embodiments, as shown in Table 2, in addition to the first encoded fragment information, the frag_count in the fragment start code blocks of the first to fourth subsequent encoded fragment information are 0xE6, 0x4C, 0x7F, and 0xB3, respectively, and then the frag_count in the fragment start code blocks of the fifth to eighth subsequent encoded fragment information are 0xE6, 0x4C, 0x7F, and 0xB3, respectively; since this repeats in this manner, further explanation is omitted here.

[0086] Based on the above analysis, in one embodiment, since multiple pieces of second traffic information are not fragmented and encoded simultaneously, only one pair of SMD-S and SMD-C may be borne for the fragment start code block of the encoded fragment information whose transmission has been interrupted. For example, SMD-S0 is borne for the fragment start code block of the first encoded fragment information, and SMD-C0 is borne for the fragment start code block of the other subsequent encoded fragment information, where SMD-S0 indicates that the fragment start code block of the first encoded fragment information is the true start code block and the first end code block after the fragment start code block is a pseudo end code block, and SMD-C0 indicates that the fragment start code block of the other subsequent encoded fragment information is a pseudo start code block, but this is not particularly limited.

[0087] In another embodiment, a true end code block or a pseudo end code block may be defined according to the 802.3br standard, for example, if the cyclic redundancy check (CRC) value of the second traffic information carried by the encoded fragment information is correct, the fragment end code block of the encoded fragment information is a true end code block, or if the combined cyclic redundancy check (mCRC) value of the second traffic information carried by the encoded fragment information is correct, the fragment end code block of the encoded fragment information is a pseudo end code block, and is not particularly limited here.

[0088] In the above example, when the second traffic information is to be carried at the location of the second cell, the second traffic information (e.g., client message) is subjected to fragment encoding, and each encoded fragment information is placed at the location of the second cell. Here, the fragmentation process is merely an intermediate process in placing the second traffic information at the location of the second cell, and in some embodiments, the process of fragmenting the second traffic information may be omitted.

[0089] For example, the process of placing the client message in the second cell position is to extract the client message bytes, encode the client message bytes according to the order and rules, and place them in the second cell position, where the rules are as follows:

[0090] First, if the content of the client message bytes to be placed at the first code block position of the second cell, i.e., the first code block position, is the start flag of the client message (preamble and frame delimiter bytes), and the start code block of the message is obtained by encoding the client message content, the start code block corresponding to the client message start flag may be placed at the first code block position of the second cell, and at the same time, this start code block may include a cell code block type flag value indicating that this start code block is the start code block of the client message, even though it is the start code block of the second cell. If the client message byte content is placed at the first code block position of the second cell instead of the start flag content of the client message (preamble and frame delimiter bytes), a pseudo start code block is placed at the first code block position of the second cell, and a cell code block type flag value indicating that this start code block is a pseudo start code block is included in this start code block, i.e., this start code block is not the start code block of the client message, but is simply the start code block of the second cell. Then, the client message byte content is sequentially placed at a position following the start code block of the second cell. In addition, the cell code block type flag value may indicate whether the start code block of the second cell is a true start code block or a pseudo start code block, and may also indicate whether the end code block after the start code block of the current second cell is a true end code block or a pseudo end code block.

[0091] Next, the client message content is sequentially placed between the start code block and the end code block of the second cell, the client message content is encoded, and an encoded code block resulting from the encoded client message is placed therein.

[0092] Finally, if the client message code block to be placed at the position of the end code block of the second cell, i.e., the position of the last code block, is the last byte content of the client message corresponding to the end code block that encodes the content of the client message, the end code block that encodes the client message is placed at the position of the end code block of the second cell. If the client message content to be placed at the position of the start code block of the second cell is not the last byte content of the client message, the encoded code block is not the end code block of the client message. In this case, the client message content bytes need to be extracted, encoded into a pseudo end code block, and placed at the position of the end code block of the second cell. This indicates that the end code block of the second cell is not the end code block of the client message, i.e., it is not a true end code block. Whether the end code block is a true end code block or a pseudo end code block may be indicated by the pseudo start code block next to the end code block. Since pseudo end code blocks and pseudo start code blocks appear in pairs, if the start code block following the end code block is a pseudo start code block, the immediately preceding end code block is a pseudo end code block, and if the start code block following the end code block is a true start code block, the immediately preceding end code block is a true end code block. In addition to forward indication, backward indication is also possible, and in implementation, a cell code block type flag value indicating whether the end code block following the start code block of the second cell is a true end code block or a pseudo end code block may be included in the immediately preceding start code block of the second cell.

[0093] Furthermore, if the cell stream includes at least two adjacent second cells, the at least two adjacent second cells are treated as one target cell, and the client message is placed at the position of the target cell. When placing the client message, both the position of the end code block of the former second cell and the position of the start code block of the latter second cell are used to place the client message.

[0094] In the process of placing a client message, if there is no client message, a code block such as an idle code block, a pseudo start code block, or a pseudo end code block may be placed instead of the client message.

[0095] In the above disposition method, the fragmentation process is not shown, but the purpose of fragmenting and disposing the client message is achieved.

[0096] In one embodiment, as shown in FIG. 21, the traffic information processing method may further include, but is not limited to, step S410, step S420, and step S430.

[0097] Step S410: Determine the cell structure and cell position of each cell in the cell stream.

[0098] In one possible embodiment, in the process of transmitting the cell stream, the cell position of each cell in the cell stream remains unchanged, and the cell position may be determined according to the time when the cell completes the bearer of traffic information, and is not particularly limited here.

[0099] In one possible embodiment, the cell may include at least one of an overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information, but is not limited thereto. As shown in FIG. 22, the start code block of this cell does not include traffic type information but includes an overhead field OH. Also, as shown in FIG. 23, the location in the cell where the overhead field is filled is called the overhead area, and the location where information such as indication information indicating the sequential relationship between cells, traffic type information, or fault indication information is filled is called the payload area. The payload area may be divided into multiple subslots, and each subslot may bear one piece of information. The subslots may be represented by SL1, SL2, ..., SLm, where m is a positive integer and is not limited thereto. For example, as shown in FIG. 24, FIG. 24 is a schematic diagram of normal Ethernet traffic information being carried in the payload area.

[0100] In one possible embodiment, the cell in the cell stream may be the first cell, or the second cell, or the first cell and the second cell, and the cell structure of the first cell and the cell structure of the second cell may be the same, but this is not particularly limited here.

[0101] In one possible embodiment, the cell structure of a cell is composed of multiple 66-bit code blocks, all defined by the 64B / 66B encoding rule, i.e., a sequential assembly of a cell start code block, a cell data code block, and a cell end code block. Here, the number of cell data code blocks for bearing at least one of an overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information is not limited. The cell start code block is a cell start flag, and the content of the cell start code block can be filled according to the content of an Ethernet message preamble and a frame interval. The cell end code block is a cell end flag. As shown in Figure 4, S''' indicates the cell start code block, D''' indicates the cell data code block, and T''' indicates the cell end code block. Since the cell start code block is also a 66-bit code block, the last 7 bytes of the cell start code block may bear at least one of an overhead field, indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. Similarly, the last few bytes of the end code block may bear at least one of an overhead field, an indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. For example, the last 7 bytes in T7 may bear a 7-byte overhead field, an indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. As shown in Figure 5, each unfilled cell represents a byte position that can be used to fill at least one of an overhead field, an indication information indicating the sequential relationship between cells, traffic type information, or fault indication information. Also, as shown in Figure 6, both the first cell and the second cell include sequence numbers 1, 2, ..., X (X is a positive integer), and these sequence numbers appear cyclically from 1 to X. These sequence numbers may be used to determine the position of each cell, but are not particularly limited here.

[0102] Step S420: Determine a first cell in the cell stream based on the cell structure, the cell location, and the first traffic information.

[0103] Step S430: Determine a second cell in the cell stream based on the cell structure, the cell location, and the second traffic information.

[0104] In one possible embodiment, the first cell and the second cell have the same length, and both the first cell and the second cell have a cell start code block, a cell data code block, and a cell end code block. The cell structure of the first cell and the cell structure of the second cell may both be composed of a cell start code block, a cell data code block, and a cell end code block, in that order.

[0105] In this embodiment, by adopting the traffic information processing method including the above steps S410 to S430, the cell structure and cell position of each cell in the cell stream can be determined, and then the first cell can be determined in the cell stream based on the cell structure, cell position, and first traffic information, and the second cell can be determined in the cell stream based on the cell structure, cell position, and second traffic information.

[0106] As an example, in a scenario in which a client message is fragmented and encoded before transmitting a second cell, from a first client message, the start code block S' of the first packet of the client message is placed in the cell start code block S''' of the first second cell in a cell location. If the fragment encoding of the client message is not completed at the last code block location of the cell location of the second cell, a cell end code block T''' is directly obtained by encoding at the last code block location of the cell location of the second cell, and then the second cell is transmitted. After that, a cell start code block S''' is obtained by encoding at the first code block location of the next second cell, and fragment encoding of the remaining part of the client message continues. Therefore, by adopting this method in this embodiment, the first block location in each cell location is always a cell start code block S''', and the last code block location in a cell location is always a cell end code block T'''.

[0107] In one embodiment, as shown in FIG. 25, step S420 will be described, which may include, but is not limited to, step S510, step S520, and step S530.

[0108] Step S510: Determine the number and bandwidth of the first traffic information.

[0109] Step S520: Determine the number of first cells for bearing the first traffic information according to the number of first traffic information and the bandwidth.

[0110] Step S530: Determine the first cell in the cell stream according to the cell structure, the cell position, and the number of the first cell.

[0111] In this embodiment, by adopting a traffic information processing method including the above steps S510 to S530, first, the number and bandwidth of the first traffic information are determined, then the number of first cells for bearing the first traffic information is determined based on the number and bandwidth of the first traffic information, and further, the first cell may be determined in the cell stream based on the cell structure, cell position, and number of first cells, but this is not particularly limited here.

[0112] In one embodiment, as shown in FIG. 26, step S430 will be described, which may include, but is not limited to, step S610, step S620, and step S630.

[0113] Step S610: Determine the number and bandwidth of the second traffic information.

[0114] Step S620: Determine the number of second cells for bearing the second traffic information according to the number of second traffic information and the bandwidth.

[0115] Step S630: Determine the second cell in the cell stream according to the cell structure, the cell position, and the number of the second cells.

[0116] In this embodiment, by adopting a traffic information processing method including the above steps S610 to S630, first, the number and bandwidth of second traffic information are determined, then the number of second cells for bearing the second traffic information is determined based on the number and bandwidth of second traffic information, and finally, the second cells may be determined in the cell stream based on the cell structure, cell position, and number of second cells, but this is not particularly limited here.

[0117] In this embodiment, as shown in FIG. 27, the traffic information processing method may further include, but is not limited to, step S710, step S720, step S730, and step S740.

[0118] Step S710: Receive a target cell stream.

[0119] Step S720: Determine a third cell that bears third traffic information and a fourth cell that bears fourth traffic information in the target cell stream.

[0120] In one possible embodiment, the third traffic information may be high-quality traffic information such as CBR traffic, high-quality Ethernet traffic information (e.g., Ethernet Common Public Radio Interface (eCPRI) traffic information), voice traffic information, video traffic information, game traffic information, etc., where the high-quality traffic information may be encapsulated in various formats such as eCPRI protocol message format or Ethernet message format, and the third traffic information may be normal Ethernet traffic information. The fourth traffic information may be normal Ethernet traffic information such as download traffic information, or may be high-quality traffic information, and is not particularly limited here.

[0121] In one possible embodiment, the third traffic information may be bearered in the third cell by mapping, and the fourth traffic information may be bearered at the location of the fourth cell by configuration, but is not particularly limited here.

[0122] Step S730: Extract third traffic information from a third cell.

[0123] In one possible embodiment, the cell structure of the third cell may be the same as the cell structure of the first cell, and will not be described here.

[0124] Step S740: Extract fourth traffic information from the fourth cell.

[0125] In one possible embodiment, the cell structure of the fourth cell may be the same as the cell structure of the second cell, and will not be described here.

[0126] In this embodiment, by adopting a traffic information processing method including the above steps S710 to S740, first, a target cell stream is received, then a third cell that bears the third traffic information in the target cell stream and a fourth cell that bears the fourth traffic information are determined, and then the third traffic information is extracted from the third cell and the fourth traffic information is extracted from the fourth cell, but this is not particularly limited here.

[0127] In one embodiment, as shown in FIG. 28, step S740 will be further described, which may include, but is not limited to, step S810 and step S820.

[0128] Step S810: Determine the pseudo start code block and the pseudo end code block in the fourth cell.

[0129] Step S820: Remove the pseudo start code block and the pseudo end code block in the fourth cell to obtain fourth traffic information.

[0130] In this embodiment, by adopting the traffic information processing method including the above steps S810 to S820, the pseudo start code block and the pseudo end code block can be determined in the fourth cell, and then the pseudo start code block and the pseudo end code block can be removed in the fourth cell to obtain the fourth traffic information, that is, after receiving the target cell stream, the pseudo start code block and the pseudo end code block can be removed in the fourth cell to retain the valid traffic information, and finally, the complete fourth traffic information can be obtained.

[0131] In all of the above embodiments, the start code block format, true start code block format, and pseudo start code block format all include the S code block format or other format types defined in the 802.3 protocol. The end code block format, true end code block format, and pseudo end code block format all include the T code block format or other format types defined in the 802.3 protocol.

[0132] Also, referring to FIG. 29, an embodiment of the present application further provides a network device 200 including a memory 202, a processor 201, and a computer program stored in the memory 202 and executable by the processor 201.

[0133] The processor 201 and the memory 202 may be connected by a bus or in some other manner.

[0134] Memory 202 may be used as a non-transitory computer-readable storage medium to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory 202 may include high-speed random access memory, as well as non-transitory memory such as at least one magnetic disk memory device, flash memory device, or other non-transitory solid-state memory device. In some embodiments, memory 202 may include memory located remotely from processor 201, which may be connected to processor 201 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0135] The non-transitory software programs and instructions necessary to realize the traffic information processing methods of the above embodiments are stored in memory 202 and, when executed by processor 201, perform the traffic information processing methods of the above embodiments, for example, steps S110 to S120 of the method of Figure 2, steps S210 to S220 of the method of Figure 7, steps S310 to S320 of the method of Figure 10, steps S410 to S430 of the method of Figure 21, steps S510 to S530 of the method of Figure 25, steps S610 to S630 of the method of Figure 26, steps S710 to S740 of the method of Figure 27, and steps S810 to S820 of the method of Figure 28.

[0136] The above-described embodiments of the equipment are merely schematic, and the units described as separate components may or may not be physically separated, i.e., located in one location or distributed across multiple network elements. Some or all of these modules may be selected according to actual needs to achieve the objectives of the aspects of this embodiment.

[0137] Furthermore, an embodiment of the present application further provides a computer-readable storage medium having computer-executable instructions stored thereon, which, when executed by a processor or controller, perform, for example, steps S110 to S120 of the method of FIG. 2, steps S210 to S220 of the method of FIG. 7, steps S310 to S320 of the method of FIG. 10, steps S410 to S430 of the method of FIG. 21, steps S510 to S530 of the method of FIG. 25, steps S610 to S630 of the method of FIG. 26, steps S710 to S740 of the method of FIG. 27, and steps S810 to S820 of the method of FIG. 28.

[0138] Furthermore, one embodiment of the present application provides a computer program product including a computer program or computer instructions stored in a computer-readable storage medium, wherein a processor of the computer device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the computer device to perform the traffic information processing methods in the above embodiments, for example, steps S110 to S120 of the method of FIG. 2, steps S210 to S220 of the method of FIG. 7, steps S310 to S320 of the method of FIG. 10, steps S410 to S430 of the method of FIG. 21, steps S510 to S530 of the method of FIG. 25, steps S610 to S630 of the method of FIG. 26, steps S710 to S740 of the method of FIG. 27, and steps S810 to S820 of the method of FIG. 28.

[0139] In the embodiment of the present application, the second traffic information is located at the position of the second cell, and the second traffic information at the position of the second cell is directly transmitted, thereby omitting the mapping process of bearing the second traffic information to the cell in a mapping manner, and therefore the mapping process can be simplified, and not only the bearer efficiency can be improved, but also the bandwidth utilization rate can be improved.

[0140] All or part of the steps in the methods and systems disclosed above may be implemented as software, firmware, hardware, or any suitable combination thereof. Some or all of the physical components may be implemented as software executed by a processor such as a central processor, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit such as an application-specific integrated circuit. Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (e.g., computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridge, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium that can be used to store desired information and that can be accessed by a computer. Additionally, communication media typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery media as known to those skilled in the art.

Claims

1. A method for processing traffic information, comprising: mapping first traffic information to a first cell and transmitting the first cell; locating second traffic information at a location of a second cell and transmitting the second traffic information at the location of the second cell.

2. The step of locating the second traffic information at a second cell location comprises: fragmenting and encoding the second traffic information to obtain a plurality of encoded fragment information; and placing each of the encoded fragment information at the location of each of the second cells.

3. The step of locating the second traffic information at a second cell location comprises: locating the second traffic information at the location of the second cell; and encoding the second traffic information when arranging the second traffic information.

4. the length of each of the encoded fragment information is equal to the length of the second cell; or, 3. The method of claim 2, wherein the length of at least two adjacent pieces of encoded fragment information among the plurality of pieces of encoded fragment information is not equal to the length of the second cell, and the sum of the lengths of the at least two adjacent pieces of encoded fragment information is equal to an integer multiple of the length of the second cell.

5. When the second traffic information is arranged at the position of the second cell, If the cell stream includes at least two adjacent second cells, determining the at least two adjacent second cells as one target cell; The method of claim 3 , further comprising: placing the second traffic information at the location of the target cell.

6. The step of placing the second traffic information at the location of the target cell includes:

6. The method of claim 5, further comprising the steps of: placing a pseudo start code block or a true start code block at the position of the start code block of each of the second cells among the target cells; placing a pseudo end code block or a true end code block at the position of the end code block of each of the second cells; and placing the second traffic information between the start code block and the end code block of each of the second cells.

7. 7. The method of claim 6, wherein the true start code block is located at the start code block position of the first of the second cells among the target cells, the pseudo start code block is located at the start code block position of a cell other than the first of the second cells among the target cells, the true end code block is located at the end code block position of the last of the second cells among the target cells, and the pseudo end code block is located at the end code block position of a cell other than the last of the second cells among the target cells.

8. the second traffic information includes at least one packet; The step of fragmenting and encoding the second traffic information to obtain a plurality of encoded fragment information includes: fragmenting and encoding each of the packets to obtain a plurality of encoded code blocks; and assembling a plurality of the encoded code blocks according to a preset rule to obtain a plurality of encoded fragment information.

9. The predetermined rule is: the same encoded fragment information includes the encoded code blocks of the same packet; or the same encoded fragment information includes the encoded code blocks of multiple packets; or The same encoded fragment information includes a target code block assembly block and the encoded code blocks of the packet; or The method of claim 8 , wherein the encoded fragment information that is the same includes at least one of a target code block assembly block.

10. 9. The method of claim 8, wherein when placing the encoded fragment information at the position of the second cell, a pseudo start code block or a start code block of a target packet is placed at the position of the start code block of the second cell, and a pseudo end code block or an end code block of the target packet is placed at the position of the end code block of the second cell.

11. 9. The method of claim 8, wherein, between at least two adjacent pieces of encoded fragment information, the former piece of encoded fragment information does not set a fragment end code block, and the latter piece of encoded fragment information does not set a fragment start code block.

12. 10. The method of claim 9, wherein if the encoded fragment information includes the target code block assembly block, the target code block assembly block includes at least one of an idle code block, a pseudo start code block, or a pseudo end code block.

13. 9. The method of claim 8, wherein the starting code block of the packet includes a message code block type flag value for determining a type of the starting code block of the current packet, a type of the ending code block of the immediately preceding packet, and a type of the ending code block after the starting code block of the current packet.

14. When the message code block type flag value is a first preset value, the message code block type flag value indicates that the current start code block is a true start code block and the end code block after the current start code block is a true end code block, the true start code block indicates that the start code block is not the start code block of the second cell but the start code block of the packet, and the true end code block indicates that the end code block is not the end code block of the second cell but the end code block of the packet; or, 14. The method of claim 13, wherein, when the message code block type flag value is a second preset value, the message code block type flag value indicates that the current start code block is a true start code block, and that an end code block after the current start code block is an end code block of the packet but an end code block of the second cell, and the true start code block indicates that the start code block is not an end code block of the second cell but an end code block of the packet.

15. 9. The method of claim 8, wherein the starting code block of the second cell includes cell code block type flag values for determining a type of the starting code block of the current second cell, a type of the ending code block of the immediately preceding second cell, and a type of the ending code block after the starting code block of the current second cell.

16. When the cell code block type flag value is a third preset value, the cell code block type flag value indicates that the start code block of the current second cell is the start code block of the packet, but is also the start code block of the second cell, and the end code block after the start code block of the current second cell is a true end code block, and the true end code block indicates that the end code block is not the end code block of the second cell but the end code block of the packet; or, When the cell code block type flag value is a fourth preset value, the cell code block type flag value indicates that the start code block of the current second cell is the start code block of the packet, but is also the start code block of the second cell, and the end code block after the start code block of the current second cell is a pseudo end code block, and the pseudo end code block indicates that the end code block is not the end code block of the packet but the end code block of the second cell; or, When the cell code block type flag value is a fifth preset value, the cell code block type flag value indicates that the start code block of the current second cell is a pseudo start code block and the end code block after the start code block of the current second cell is a true end code block, the pseudo start code block indicating that the start code block is not the start code block of the packet but the start code block of the second cell, and the true end code block indicating that the end code block is not the end code block of the second cell but the end code block of the packet; or, 16. The method of claim 15, wherein, when the cell code block type flag value is a sixth preset value, the cell code block type flag value indicates that a start code block of the current second cell is a pseudo start code block and an end code block after the start code block of the current second cell is a pseudo end code block, the pseudo start code block indicates that the start code block is not a start code block of the packet but is a start code block of the second cell, and the pseudo end code block indicates that the end code block is not a end code block of the packet but is an end code block of the second cell.

17. the start code block format, the true start code block format, and the pseudo start code block format all comprise the S code block format defined in the 802.3 protocol; 17. The method of claim 16, wherein the format of the end code block, the format of the true end code block, and the format of the pseudo end code block all comprise a T-code block format defined in the 802.3 protocol.

18. determining a cell structure and a cell position for each cell in the cell stream; determining the first cell in the cell stream based on the cell structure, the cell location, and the first traffic information; determining the second cell in the cell stream based on the cell structure, the cell location, and the second traffic information; 2. The method of claim 1, wherein the cell position in the cell stream remains unchanged.

19. 20. The method of claim 18, wherein the cells include at least one of an overhead field, an indication indicating an ordering relationship between the cells, traffic type information, or fault indication information.

20. determining the first cell in the cell stream based on the cell structure, the cell location, and the first traffic information, determining the number and bandwidth of the first traffic information; determining the number of the first cells for bearing the first traffic information based on the number of the first traffic information and a bandwidth; and determining the first cell in the cell stream based on the cell structure, the cell location, and the number of first cells.

21. determining the second cell in the cell stream based on the cell structure, the cell location, and the second traffic information; determining the number and bandwidth of the second traffic information; determining the number of second cells for bearing the second traffic information based on the number of second traffic information and a bandwidth; and determining the second cell in the cell stream based on the cell structure, the cell location, and the number of second cells.

22. 20. The method of claim 18, wherein the first cell and the second cell are the same length, and the first cell and the second cell both have a cell start code block, a cell data code block, and a cell end code block.

23. receiving a target cell stream; determining a third cell that bears third traffic information and a fourth cell that bears fourth traffic information in the target cell stream; extracting the third traffic information from the third cell; The method of claim 1 , further comprising: extracting the fourth traffic information from the fourth cell.

24. The step of extracting the fourth traffic information from the fourth cell comprises: determining a pseudo start code block and a pseudo end code block in the fourth cell; and removing the pseudo start code block and the pseudo end code block in the fourth cell to obtain the fourth traffic information.

25. 2. The method of claim 1, wherein the position of the first cell in the cell stream is different from the position of the second cell in the cell stream.

26. A network device comprising: a memory; a processor; and a computer program stored in the memory and executable by the processor, the computer program executing the processor to implement the method of any one of claims 1 to 25.

27. A computer-readable storage medium having stored thereon computer-executable instructions for carrying out the method of any one of claims 1 to 25.

Images