Traffic information processing methods, network devices, and storage media

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 with an application number of 202210968517.4 and a filing date of August 12, 2022, and claims the priority of the Chinese patent application. All the contents of the Chinese patent application are incorporated herein by reference.

[0002] The embodiments of this application relate to the technical field of communications, but are not limited thereto. In particular, they relate to a method for processing traffic information, network devices, and storage media.

Background Art

[0003] In network communication, there are two types of traffic: high-quality service traffic and normal Ethernet (registered trademark) traffic. In the case of high-quality service traffic, it is necessary to enjoy a dedicated bearer pipeline alone. For example, some cells can be borne alone. In the case of normal Ethernet traffic, for example, it does not require a dedicated bearer pipeline, such as multiple normal Ethernet traffics being borne in one cell. However, in the related art, before bearing normal Ethernet traffic, it is necessary to encode normal Ethernet traffic information with 64B / 66B, convert the encoded 66-bit code block into a bit stream or bytes, and map it to the payload area of the cell for bearing. However, this process complicates the traffic bearing by the cell, reduces the bearing efficiency of the cell, and as a result, bandwidth waste is likely to occur.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The embodiments of this application provide a method for processing traffic information, network devices, and storage media.

Means for Solving the Problems

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

[0006] In a second embodiment, the present invention further provides a network device comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor, upon execution of the computer program, implements the above-described method for processing traffic information.

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

[0008] In a fourth embodiment, the embodiment of the present application further provides a computer program product which includes a computer program or computer instruction stored on a computer-readable storage medium, wherein a processor of a computer device reads the computer program or computer instruction from the computer-readable storage medium, and when the processor executes the computer program or computer instruction, causes the computer device to execute the above-described traffic information processing method. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic diagram of a bearer in a cell for high-quality-of-service traffic and Ethernet traffic according to one embodiment of the present invention. [Figure 2] This is a flowchart of a method for processing traffic information according to one embodiment of the present invention. [Figure 3] This is a schematic diagram of a bearer in a traffic information cell of an Ethernet general-purpose public wireless interface according to an example of the present invention. [Figure 4] This is a schematic diagram of a cell structure according to an example of the present invention. [Figure 5] This is a schematic diagram of a cell structure according to another example of the present invention. [Figure 6] This is a schematic diagram of a cell containing a sequence number according to one embodiment of the present invention. [Figure 7] Figure 2 is a flowchart of the method in step S120. [Figure 8] This is a flowchart of fragment coding of second traffic information according to one embodiment of the present invention. [Figure 9] This is a schematic diagram illustrating the case where the lengths of two adjacent encoded fragments are not equal, according to one embodiment of the present invention. [Figure 10] Figure 7 is a flowchart of the method in step S210. [Figure 11] This is a schematic diagram of cell locations corresponding to first traffic information and second traffic information according to one embodiment of the present invention. [Figure 12] This is a schematic diagram illustrating the cancellation of the start and end code blocks between two adjacent target coded fragments according to one embodiment of the present invention. [Figure 13] A schematic diagram of encoded fragment information in the case of no target packet according to one embodiment of the present invention. [Figure 14] This is a schematic diagram of the start code block of normal Ethernet traffic information according to one embodiment of the present invention. [Figure 15] This is a schematic diagram of the start code block of the second cell according to one embodiment of the present invention. [Figure 16] This is a schematic diagram of the start code block of the second cell according to another embodiment of the present application. [Figure 17] This is a schematic diagram of the start code block of the second cell that bears a fragment sequence number according to one embodiment of the present invention. [Figure 18] This is a schematic diagram of the case in which the start code block of the second cell bears a fragment sequence number according to one embodiment of the present invention. [Figure 19] Schematic diagram of the field content of the first encoded fragment information with transmission interrupted according to an embodiment of the present application. [Figure 20] Schematic diagram of the field content of subsequent encoded fragment information with transmission interrupted according to an embodiment of the present application. [Figure 21] Flowchart of a method for processing traffic information according to another embodiment of the present application. [Figure 22] Schematic diagram of the structure of a cell start code block without traffic type information according to an embodiment of the present application. [Figure 23] Schematic diagram of a cell structure according to another example of the present application. [Figure 24] Schematic diagram when normal Ethernet traffic information is borne in the payload area according to an example of the present application. [Figure 25] Flowchart of the method of step S420 in FIG. 21. [Figure 26] Flowchart of the method of step S430 in FIG. 21. [Figure 27] Flowchart of a method for processing traffic information according to another embodiment of the present application. [Figure 28] Flowchart of the method of step S740 in FIG. 27. [Figure 29] Schematic diagram of a network device according to an embodiment of the present application.

Embodiments for Carrying Out the Invention

[0010] To make the object, technical solution and advantages of the present application clearer, the present application will be described in detail below with reference to the drawings and embodiments. The embodiments described in this specification are for explaining the present application and not for limiting the present application.

[0011] Although the flowchart shows a logical order, in some cases the steps illustrated or described may be performed in a different order than the flowchart. In the description of the specification, claims, and the drawings above, the meaning of "plural" (or "plural clauses") is two or more, and it should be understood that "greater than," "less than," "greater than," etc., do not include the number, while "greater than or equal to," "less than or equal to," "within," etc., do include the number. When there are descriptions such as "first," "second," etc., they are solely for the purpose of distinguishing technical features and should not be understood as indicating or implying relative importance, implying the number of technical features being described, or implying the sequence of technical features being described.

[0012] The embodiment of the present application includes the steps of mapping first traffic information to a first cell and transmitting the first cell, and placing second traffic information at the location of a second cell and transmitting the second traffic information at the location of the second cell. In other words, by placing the second traffic information at the location of a second cell and directly transmitting the second traffic information at the location of the second cell, the mapping step of mapping and bearing the second traffic information within the cell is omitted, and therefore the mapping step can be simplified, improving not only bearer efficiency but also bandwidth utilization.

[0013] Furthermore, in communication networks, changes in information content also change the structure of the communication network. Traditionally, communication content has mainly consisted of voice traffic, which 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 capable of providing low-latency, low-jitter, and highly reliable bearer services. Here, low latency refers to a delay below a predetermined delay value, low jitter refers to a jitter value below a predetermined jitter value, and high reliability means that quality of service (QoS) can be ensured for various traffic priorities. The predetermined delay value and predetermined jitter value may be set according to the actual situation. Furthermore, synchronous digital hierarchy (SDH) networks and optical transport network (OTN) bearer networks can provide dedicated bearer pipelines for the transmission of voice traffic. This allows voice traffic to be bearered on communication networks based on SDH and OTN technologies, which greatly meets the bearer demand for voice traffic, although the bearer costs of dedicated bearer pipelines are relatively high.

[0014] With the advancement of communication technology, the main bearer content in current communication networks is message traffic with an Ethernet structure, and communication network technology is also shifting to Ethernet technology. Ethernet technology employs a statistical multiplexing scheme, transmitting client traffic in a shared manner; that is, all client traffic shares the same bearer pipeline using the statistical multiplexing scheme, and this bearer pipeline bears client traffic on a best-effort basis. Therefore, while Ethernet technology's shared multiplexing scheme can conserve bearer pipeline utilization, improve bearer efficiency, and reduce bearer costs, it results in lower service quality.

[0015] Most Ethernet traffic is normal traffic, i.e., regular Ethernet traffic, which has very low requirements for bearer quality but demands high bearer efficiency and low bearer costs. Therefore, how to achieve joint bearing of high-quality-of-service (QSA) traffic and regular Ethernet traffic while meeting the bearer quality requirements for QSA traffic is an urgent issue that needs to be resolved.

[0016] In related technologies, cells are isolated from each other and do not affect one another. Therefore, if high-quality-of-service (QS) traffic is transmitted through some cells and normal Ethernet traffic is transmitted through other cells, the QS traffic and normal Ethernet traffic are isolated from each other and do not affect one another, thereby allowing QS traffic and normal Ethernet traffic to be transmitted together in a single physical pipeline.

[0017] As shown in Figure 1, when normal Ethernet traffic is transmitted at rates of 10G or higher (e.g., 25G, 50G, 100G, 200G, 400G, etc.), this normal Ethernet traffic must undergo 64B / 66B encoding before transmission. This means that first, 8 bytes (i.e., 64 bits) of data information are extracted from the packet, a 2-bit synchronization header is added before this 64-bit data information, the 64-bit information code block is expanded into a 66-bit information code block, this 66-bit information code block is converted into a bitstream (or byte), mapped to the payload area of ​​the cell and bearered, and finally this cell is transmitted. When the receiving end receives this data stream, it identifies the 66-bit information code block from the data stream, recovers the original 64-bit data information from the information code block, and then reassembles the 64-bit data information into the original packet. A 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, high-quality-of-service traffic (e.g., CBR traffic) only needs to be directly mapped to the first cell and transmitted through the first cell.

[0018] In the case of normal Ethernet traffic, only the 64-bit position within the data code block of one cell can bear the normal Ethernet traffic; therefore, encoded normal Ethernet traffic information (i.e., a 66-bit code block) needs to be carried across the data code blocks of two cells. Furthermore, because the 66-bit code block corresponding to normal Ethernet traffic needs to be carried within the cell's data code block by a mapping scheme, this introduces complexity to the process of converting bit code blocks to bitstreams or bytes. Moreover, the bearer efficiency of cells is limited, and the smaller the cell, the lower the bearer efficiency, so the method of bearing normal Ethernet traffic to cells using a mapping scheme leads to bandwidth waste. Based on this, 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 packet start code block is denoted by S', the packet end code block by T', the fragment start code block by S'', the fragment end code block by T'', the cell start code block by S''', the cell end code block by T''', the packet data code block by D', and the fragment data code block by D''.

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

[0021] Figure 2 is a flowchart of a traffic information processing method according to one embodiment of the present invention. This traffic information processing method may include, but is not limited to, steps S110 and S120.

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

[0023] Step S120: Place 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 feasible embodiment, the first traffic information may be, for example, CBR traffic, high-quality-of-service (KSI) Ethernet traffic information (e.g., Ethernet Common Public Radio Interface (eCPRI: ethernet®) traffic information), voice traffic information, video traffic information, game traffic information, and other KSI traffic information. Of these, the KSI traffic information may be encapsulated in various formats such as the eCPRI protocol message format or the Ethernet message format, and the first traffic information may be ordinary Ethernet traffic information. The second traffic information may be, for example, ordinary Ethernet traffic information such as download traffic information, or KSI traffic information, and is not particularly limited here.

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

[0027] In one feasible embodiment, the first or second cell may bear an Ethernet interface, a Flexible Ethernet (FlexE) time slot, or any other physical or logical interface capable of bearing the cell, and is not limited herein.

[0028] Since the content transmitted over the Ethernet interface is a 66-bit code block, the first cell bearing the first traffic information and the second cell bearing the second traffic information are also composed of 66-bit blocks, enabling direct transmission and reception of these cells over the Ethernet interface. Of the 66-bit code block defined by the 64B / 66B coding rules, the first two bits are the code block's synchronization header. Of these two bits, the synchronization header is fixed to "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) filled with 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), where the content of the first byte immediately following the synchronization header indicates the type of control code block, and the content of the following seven bytes is the content of the control code block (e.g., data information, control information, or data information and control information), and the content of these seven bytes is determined by the type of control code block. Furthermore, the control code block includes 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 the start flag for one data code block and the end code block is the end flag for one data code block. In addition, in the Ethernet 802.3 standard, end code blocks are classified into eight types: T0, T1, T2, T3, T4, T5, T6, and T7. T0 has a first byte content of 0x87 and does not bear at least one of the following: an overhead field, instruction information indicating inter-cell order relationships, traffic type information, or fault instruction information. T1 has a first byte content of 0x99 and bears at least one of the following: a one-byte overhead field, instruction information indicating inter-cell order relationships, traffic type information, or fault instruction information.T2 has a first byte content of 0x99 and bears at least one of the following: a two-byte overhead field, instruction information indicating the order relationship between cells, traffic type information, or fault instruction information. In this way, T7 has a first byte content of 0x99 and bears at least one of the following: a seven-byte overhead field, instruction information indicating the order relationship between cells, traffic type information, or fault instruction information.

[0029] In one feasible embodiment, the cell structures of the first and second cells are each constructed by sequentially assembling multiple 66-bit code blocks defined by 64B / 66B coding rules, 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 the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instructional information; the cell start code block is the cell start flag; and the cell end code block is the 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 the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instructional information. Similarly, the last few bytes of the exit code block may bear at least one of the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. For example, the last seven bytes of T7 may bear at least one of the following: a seven-byte overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. As shown in Figure 5, each unfilled cell represents a byte location that can be used to fill at least one of the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. Also, as shown in Figure 6, both the first and second cells contain sequence numbers 1, 2, ..., X (where X is a positive integer), which appear cyclically from 1 to X, and these sequence numbers may, but are not limited to, be used to determine the position of each cell.

[0030] In this embodiment, a traffic information processing method including steps S110 to S120 described above is employed. Specifically, the first traffic information is mapped to the first cell, the first cell is transmitted, the second traffic information is placed at the location of the second cell, and the second traffic information at the location of the second cell is transmitted. The location of the first cell in the cell stream and the location of the second cell in the cell stream are different. That is, by placing the second traffic information at the location of the second cell and directly transmitting the second traffic information at that location of the second cell, the mapping process of mapping and bearing the second traffic information within the cell is omitted. Therefore, the mapping process can be simplified, improving not only bearer efficiency but also bandwidth utilization.

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

[0032] Step S210: The second traffic information is fragmented and encoded to obtain multiple encoded fragments.

[0033] In one feasible 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: Place each encoded fragment information at the position of each second cell.

[0035] In one feasible embodiment, there may be only one second cell in a single cell period. Alternatively, a single cell period may contain multiple second cells with different sequence numbers. For example, a single cell period may contain 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 periods may contain second cells with the same sequence number. For example, a first cell period may contain a second cell with sequence number 1 and a second cell with sequence number 2, and a second cell period may also contain a second cell with sequence number 1 and a second cell with sequence number 2, and this is not particularly limited here.

[0036] In one feasible embodiment, the length of the encoded fragment information may be the same as the length of the second cell. After placing each encoded fragment information at the position of the second cell, the fragment start code block of each encoded fragment information is placed at the start code block position of the second cell, and the fragment end code block of each encoded fragment information is placed at the end code block position of the 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 containing four packets, packet1, packet2, packet3, and packet4, when encoding each packet of this client message in 64B / 66B, the client message may be fragmented such that each encoded fragment information is 7 code blocks long to obtain multiple encoded fragment information, and then each encoded fragment information of length 7 code blocks may be placed at the position of the second cell. However, this is not particularly limited here.

[0037] In one feasible embodiment, bearer efficiency is improved by reducing at least one pair of pseudo-end and pseudo-start code blocks, such that the lengths of at least two adjacent coded fragments among the multiple coded fragments are not equal to the length of the second cell, and the sum of the lengths of these at least two adjacent coded fragments is equal to an integer multiple of the length of the second cell. Then, after placing each coded fragment at the position of each second cell, the fragment start code block of each coded fragment is placed at the position of the start code block of each second cell, and the fragment end code block of each coded fragment is placed at the end code block of each second cell. The fragment start code block and the fragment end code block belong to different coded fragment information. For example, assuming that the length of the second cell is 7 code blocks, this second traffic information may be fragment-encoded into coded fragment information of one length of 3 code blocks, coded fragment information of one length of 4 code blocks, and multiple coded fragment information of a length of 7 code blocks. Alternatively, as shown in Figure 9, this second traffic information may be fragment-encoded into encoded fragment information of one length 8 code blocks (i.e., third encoded fragment information), encoded fragment information of one length 6 code blocks (i.e., fourth encoded fragment information), and multiple encoded fragment information of 7 code blocks in length (e.g., first encoded fragment information, second encoded fragment information, and fifth encoded fragment information). Alternatively, this second traffic information may be fragment-encoded into encoded fragment information of one length 2 code blocks, encoded fragment information of one length 5 code blocks, and multiple encoded fragment information of 7 code blocks in length, but is not particularly limited here.

[0038] In one feasible embodiment, when each encoded fragment information is completed, the encoded fragment information may be placed directly at the location of the second cell, and the second traffic information at the location of the second cell may be transmitted. That is, the second traffic at the location of the second cell can be transmitted while the second traffic information is fragmented and encoded, without the need to place all the encoded fragment information together at the corresponding location of the second cell after completion, nor is it necessary to transmit all the second traffic information together after placing all the encoded fragment information in the second cell.

[0039] In this embodiment, by employing a traffic information processing method including steps S210 to S220 described above, the second traffic information can be fragmented and encoded to obtain multiple encoded fragments, and then each encoded fragment can be placed at the location of each second cell. Therefore, in this embodiment, a fragment encoding method can be employed to generate a sequence code block from a client message, and the sequence code block can be directly transmitted at the cell location. This solves the problems of complexity and low cell bearer efficiency that arise from bearing the code block of the client message to the cell using a mapping method.

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

[0041] Based on the embodiments described above, when placing the second traffic information at the location of the second cell, if the cell stream contains at least two adjacent second cells, these at least two adjacent second cells are treated as a single target cell, and the second traffic information is placed at the location of the target cell. In some embodiments, a pseudo-start code block or a true start code block is placed at the start code block location of each second cell among the target cells, a pseudo-end code block or a true end code block is placed at the end code block location 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, a 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; a 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; a 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 a 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 feasible embodiment, the true start code block is located at the position of the start code block of the first second cell among the target cells, the pseudo start code block is located at the position of the start code block of any cell other than the first second cell among the target cells, the true end code block is located at the position of the end code block of the last second cell among the target cells, and the pseudo end code block is located at the position of the end code block of any cell other than the last second cell among the target cells, but this is not particularly limited.

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

[0044] Step S310: Fragment and encode each packet to obtain multiple encoded code blocks.

[0045] In one feasible embodiment, packets may be encoded in 64B / 66B. When encoding packets in 64B / 66B, the packet's preamble and frame gap may be encoded as the start code block, the middle data portion of the packet as the data code block, and the remaining portion of the packet's data as the end code block. Thus, the encoded code blocks of a packet are divided into a start code block, a data code block, and an end code block, but are not particularly limited here.

[0046] Step S320: Multiple coded code blocks are assembled according to a pre-set rule to obtain multiple coded fragment information.

[0047] In one feasible embodiment, the pre-defined rules may include, but are not limited to, at least one of the following: identical coded fragment information includes coded code blocks of the same packet; identical coded fragment information includes coded code blocks of multiple packets; identical coded fragment information includes a target code block assembly block and a coded code block of a packet; and identical coded fragment information includes a target code block assembly block.

[0048] In one embodiment, taking as an example the case where a pre-configured rule includes the fact that identical coded fragment information includes coded code blocks from multiple packets, and identical coded fragment information includes coded code blocks from the same packet, if the sum of the lengths of the multiple coded code blocks corresponding to the same target packet is less than the length of the coded fragment information, the multiple coded code blocks of the target packet and the coded code blocks of the adjacent packets of the target packet are assembled to form identical coded fragment information. Here, this identical coded fragment information includes the start code block of the target packet and the end code block of the adjacent packets, or this identical coded fragment information includes the end code block of the target packet and the start code block of the adjacent packets. If the sum of the lengths of the multiple coded code blocks corresponding to the same target packet is greater than the length of the coded fragment information, the multiple coded code blocks of the same packet may be assembled to form identical coded fragment information, but this is not particularly limited here.

[0049] In some embodiments, as shown in Figure 8, assuming that the length of each encoded fragment information is 7 code blocks and the second traffic information contains 5 packets, packet1, packet2, packet3, and packet4, when packet1 is fragmented and encoded, 5 encoded code blocks are obtained. Of these, the first encoded code block is the start code block S' of packet1, which is also the fragment start code block S'' of the first encoded fragment information, and 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 the start code block S' of the target packet. Since the sum of the lengths of the 5 encoded code blocks of packet1 is less than the length of the encoded fragment information, the fragment encoding of packet2 is continued to obtain the start code block S' of packet2, and then packet2 is fragmented and encoded to obtain the 7th encoded code block. This encoded code block can be the fragment end code block T'', and finally, the 7 obtained encoded code blocks are assembled to obtain the first 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, this encoded fragment information may be directly placed at the corresponding second cell location, the fragment start code block of this encoded fragment information may be placed at the start code block location of the second cell, the fragment end code block of this encoded fragment information may be placed at the end code block location of the second cell, and the second traffic information at this second cell location may be transmitted. Subsequently, the assembly of the second encoded fragment information is continued. First, the remaining part of packet2 is fragmented and encoded to obtain one encoded code block, and this encoded code block is 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). Then, packet2 is fragmented and encoded to sequentially obtain five encoded code blocks, and these five encoded code blocks are designated as the fragment data code block D''. Finally, packet2 is fragmented and encoded to obtain a seventh encoded code block, and this encoded code block is designated as the fragment end code block T''. Finally, the obtained seven encoded code blocks are assembled to obtain the second encoded fragment information.

[0051] Similarly, after obtaining the second coded fragment information, this coded fragment information may be directly placed at the corresponding second cell location, the fragment start code block of this coded fragment information placed at the start code block location of the second cell, the fragment end code block of this coded fragment information placed at the end code block location of the second cell, and the second traffic information at this second cell location may be transmitted. Subsequently, the assembly of the third coded fragment information continues, and since packet2 has not yet completed fragment coding, the fragment coding of packet2 continues to obtain one coded code block, and this coded code block is designated as the fragment start code block S'' of the third coded fragment information (this coded code block is not the start code block S' of packet2), and then packet2 is fragmented and coded to sequentially obtain one end code block. Here, this end code block is the end code block T' of packet2, not the fragment end code block T'' of the third coded fragment information, and at this point, the fragment coding of packet2 is completed. At this point, since the sum of the lengths of the two coded code blocks obtained by fragment coding is smaller than the length of the third coded fragment information, it is necessary to fragment and code packet3. First, packet3 is fragmented and encoded to obtain the first encoded code block, which is the start code block S' of packet3, and not the start code block S'' of the third encoded fragment information. Next, packet3 is fragmented and encoded to obtain three encoded code blocks in sequence, and each of these encoded code blocks becomes the fragment data code block D'' of the third encoded fragment information. Finally, packet3 is fragmented and encoded to obtain the seventh encoded code block, which becomes the end code block T'' of the third encoded fragment information (this block T is not the end code block T' of packet3).Finally, the seven resulting coded code blocks are assembled to obtain the third coded fragment information.

[0052] Similarly, after obtaining the third coded fragment information, this coded fragment information may be directly placed at the corresponding second cell location, the fragment start code block of this coded fragment information may be placed at the start code block location of the second cell, the fragment end code block of this coded fragment information may be placed at the end code block location of the second cell, and the second traffic information at this second cell location may be transmitted. After obtaining the third coded fragment information by assembly, since the fragment coding of packet 3 is not yet complete, the fragment coding of packet 3 is continued to obtain one coded code block, and this coded code block is designated as the fragment start code block S'' of the fourth coded fragment information, not the start code block S' of packet 3. Next, packet 3 is fragmented and coded to obtain the final coded code block, which is the end code block T' of packet 3, not the fragment end code block T'' of the fourth coded fragment information, and at this point, the fragment coding of packet 3 is complete. At this point, since the sum of the lengths of the two coded code blocks obtained by fragment coding is smaller than the length of the fourth coded fragment information, packet 4 needs to be fragmented and coded. In this way, the fourth encoded fragment information is obtained, so we will omit the explanation here.

[0053] In one feasible embodiment, the fragment end code block T'' of all encoded fragment information in the above embodiment may be 0 bytes, 1 byte, 2 bytes, 6 bytes, or 7 bytes, and if T'' has 0 bytes, T'' is T0, and T0 does not bear any contents in the packet. If T'' has 1 byte, T'' is T1, if T'' has 6 bytes, T'' is T6, and if T'' has 7 bytes, T'' is T7, but this is not particularly limited. Alternatively, once each encoded fragment information is completed, this encoded fragment information may be placed directly at the location of the second cell, the fragment start code block of this encoded fragment information may be placed at the start code block location of the second cell, the fragment end code block of this encoded fragment information may be placed at the end code block location of the second cell, and the second traffic information at this location of the second cell may be transmitted. After completing all the encoded fragment information, it is not necessary to place them together at the corresponding location of the second cell, and after placing all the encoded fragment information at the location of the second cell, it is not necessary to transmit the second traffic information at the location of the second cell together.

[0054] In one feasible embodiment, when placing encoded fragment information at the location of the second cell, the pseudo-start code block or the start code block of the target packet may be placed at the location 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 location 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 coded fragment information is 7 code blocks and the second traffic information contains one packet, i.e., packet1, if packet1 is fragmented and coded to obtain five coded code blocks in which the first coded code block is the start code block S' of packet1 and the fifth coded code block is the end code block T' of packet1, then the pseudo-start code block may be designated as the fragment start code block S'' and the pseudo-end code block as the fragment end code block T''. The pseudo-start code block, the five coded code blocks obtained by fragmenting and coding packet1, and the pseudo-end code block may be sequentially assembled to form coded fragment information. Alternatively, assuming that the target coded fragment information has a length of 7 code blocks and the second traffic information contains one packet, i.e., packet1, if packet1 is fragmented and coded to obtain 6 coded code blocks, where the first coded code block is the start code block S' of packet1 and the sixth coded code block is the end code block T' of packet1, then a pseudo-start code block may be placed in the position of the fragment start code block S'' and the end code block T' of packet1 in the position of the fragment end code block T'', and the pseudo-start code block and the 6 coded code blocks obtained by fragmenting and coding packet1 may be sequentially assembled to obtain coded fragment information, but this is not particularly limited here.

[0056] In one feasible embodiment, between at least two adjacent coded fragments, the former coded fragment does not set a fragment end code block, and the latter coded fragment does not set a fragment start code block.

[0057] In one embodiment, assuming that the length of both the first encoded fragment information and the second encoded fragment information is seven code blocks, and that the second traffic information contains two packets, packet1 and packet2, when packet1 is fragmented and encoded, nine encoded code blocks are obtained, 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. When packet2 is fragmented and encoded, five encoded code blocks are obtained, 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, where 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. Thus, the start code block S' of packet1 is carried to the fragment start code block S'' of the first encoded fragment information, the seventh encoded code block of packet1 is placed at the position of the last code block of the first encoded fragment information, the eighth encoded code block of packet1 is placed at the position of the first code block of the second encoded fragment information, and the end code block T' of packet1 is carried to the position of the second code block of the second encoded fragment information. Therefore, the second encoded fragment information does not contain the fragment start code block S''.Similarly, the start code block S' of packet2 is located at the position of the third code block in the second coded fragment information, and in this way, the end code block T' of packet2 is located at the position of the last code block in the second coded fragment information, and therefore the second coded fragment information does not contain, but is not particularly limited here, a fragment end code block T''.

[0058] Based on the above embodiment, in a scenario where the second cell is transmitted while fragmenting and encoding the second traffic information, the first encoded fragment information has a fragment start code block S''' placed at the start code block S''' of the first second cell among the cell locations. Since the first encoded fragment information does not have a fragment end code block T''', when the first encoded fragment information is placed at the location of the second cell, the end code block T''' does not exist in the second cell. Subsequently, the fragment encoding of packet1 and packet2 of the second traffic information is continued to obtain seven encoded code blocks, and these seven encoded code blocks are assembled to form the second encoded fragment information. Therefore, this second encoded fragment information does not contain a fragment start code block S''. After that, this second encoded fragment information is placed at the location of the next second cell. Therefore, the cell start code block S''' does not exist at the location of the first code block of the next second cell. Therefore, in this embodiment, by adopting this method, if an adjacent second cell is considered as one target cell, the cell's start code block S''' is always located 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 located at the position of the last code block of the latter cell (i.e., the last code block of the target cell). Among the adjacent cells, the cell's end code block T''' is not present at the position of the last code block of the former cell, and the cell's start code block S''' is not present at the position of the first code block of the latter cell.

[0059] In one embodiment, as shown in Figures 11 and 8, assuming that the first traffic information is high-quality-of-service traffic information and the second traffic information is normal Ethernet traffic information, the high-quality-of-service traffic information is mapped to three first cells, the normal Ethernet traffic information is fragmented and encoded to obtain three encoded fragments, and then these three encoded fragments are placed in the positions of three second cells. Here, a first cell exists 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. 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, so 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 (or the end code block of the second second cell and the start code block of the third second cell are adjacent). Furthermore, the fragment end code block of the second encoded fragment information is not the end code block of packet 2, and the fragment start code block of the third encoded fragment information is not the start code block of packet 2. In other words, 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, thus reducing 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 block and fragment end code block between at least two adjacent target encoded fragment information can be canceled, thereby improving bearer efficiency and facilitating the recovery of the second traffic information on the receiving side.

[0060] Based on the above embodiment, as shown in Figure 12, one data code block D' of packet 2 is placed at the position of the last code block of the second encoded fragment information, and another data code block D' of packet 2 is placed at the position of the first code block of the third encoded fragment information. Since both the fragment end code block of the second encoded fragment information and the fragment start code block of the third encoded fragment information bear normal Ethernet traffic information, this embodiment improves bearer efficiency. Furthermore, when the receiving side receives the second second cell corresponding to this 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 recovery of normal Ethernet traffic information.

[0061] In one embodiment, a pre-configured rule may include the requirement that identical coded fragment information includes a target code block assembly block and a packet's coded code block, 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 multiple coded code blocks corresponding to the same target packet is greater than the length of the coded fragment information, or if the sum of the lengths of multiple coded code blocks corresponding to the same target packet is less than the length of the coded fragment information, the multiple coded code blocks of the target packet and the target code block assembly block are assembled to form identical coded 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 coded fragment information may use a pseudo-start code block as the fragment start code block and the target packet's end code block as the fragment end code block. Alternatively, the target coded fragment information may use the target packet's start code block as the fragment start code block and a pseudo-end code block as the fragment end code block. Alternatively, the target coded 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, this target coded 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 is not particularly limited. An idle code block is a control code block obtained by coding normal Ethernet traffic information in 64B / 66B, and an idle code block is also called an idle code block or 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-termination code block is used as the fragment termination code block T'' of the encoded fragment information, and the encoded code block obtained by fragmenting and encoding the target packet and the pseudo-termination 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 less than the length of the encoded fragment information, the idle code block and the encoded code block obtained by fragment encoding may be assembled to form the same encoded fragment information, thereby ensuring that the length of each encoded fragment information is constant. Here, this idle code block may be beared at any position in the encoded fragment information, for example, the fragment start code block S'' of the encoded fragment information, the position of the code block 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, a pre-configured rule may include the requirement that identical coded 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 Embodiment 1 of Figure 13, if there is no target packet, multiple idle code blocks I may be directly assembled into coded fragment information. Alternatively, as shown in Embodiment 2 of Figure 13, the first two code blocks of the coded fragment information may be sequentially filled with pseudo-start code blocks S'''' and pseudo-end code blocks T'''', the idle code block I may be carried to the intermediate code block of the coded fragment information, and the last two code blocks of the coded fragment information may be sequentially filled with pseudo-start code blocks S'''' and pseudo-end code blocks T''''. Alternatively, as shown in Embodiment 3 of Figure 13, the code blocks of the coded fragment information may be alternately filled with pseudo-start code blocks S'''' and pseudo-end code blocks T''''.

[0065] In this embodiment, by employing a traffic information processing method including steps S310 to S320 described above, if 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 pre-set rule to obtain a plurality of encoded fragment information. Therefore, in the embodiment of the present application, the length of the encoded fragment information obtained by assembling the encoded code blocks obtained by fragmenting and encoding packets can be matched with the length of the second cell according to a pre-set rule, making it easier 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, wherein the fragment end code block may be a true end code block or a pseudo end code block, where a true end code block refers to the end code block of each packet in the second traffic information, and a 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 a true start code block refers to the start code block of each packet in the second traffic information, and a 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 the arrow is a pseudo start code block, and the fragment end code block T'' indicated by the arrow is a pseudo end code block.

[0067] A pseudo-end code block of one encoded fragment appears as a pair with a pseudo-start code block of the next encoded fragment. If the end code block of one encoded fragment is a pseudo-end code block, it indicates that the second traffic information was truncated by this pseudo-end code block, and the start code block of the next encoded fragment is always a pseudo-start code block. Conversely, if the start code block of one encoded fragment is a pseudo-start code block, it indicates that the second traffic information was truncated, so the end code block of the immediately preceding encoded fragment is always a pseudo-end code block, and the immediately preceding encoded fragment contains a portion of this second traffic information. Therefore, simply identifying whether the start code block of a fragment is a pseudo-start code block allows us to deduc whether the end code block of the immediately preceding fragment is a pseudo-end code block, and it is not necessary to mark whether the end code block of a fragment is a pseudo-end code block or not.

[0068] Furthermore, when the second traffic information is normal Ethernet traffic information, the format of the start code block of this normal Ethernet traffic information (i.e., the packet's start code block S') is generally fixed, as shown in Figure 14, when the normal Ethernet traffic information is fragmented and encoded. In Figure 14, the bit value of the synchronization header of the start code block is "10", the content of the first byte immediately following the synchronization header is "0x78", which is the type of control block, followed by six bytes of "0x55" and one byte of "0xd5", where the six bytes of "0x55" are the frame interval bytes of the Ethernet message and the one byte of "0xd5" is the frame delimiter of the Ethernet message. Since the frame interval bytes and frame delimiter are fixed contents within 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 packet's start code block S').

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

[0070] In one embodiment, taking the message code block type flag value as an example, if the message code block type flag value is a first preset value, then 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 following the current start code block is a true end code block. A true start code block indicates that the start code block is the start code block of a packet, not the start code block of a second cell, and a true end code block indicates that the end code block is the end code block of a packet, not the end code block of a second cell. For example, as shown in Figure 16, the first preset value is represented by xxxx, and assuming that the first preset value is in the 7th byte after the synchronization header in the start code block, if the first preset value xxxx is 0x55, then the current start code block is a true start code block, and the end code block following the current start code block is a true end code block. The first preset value may be in other byte positions and may be other values, but is not particularly limited here.

[0071] In another embodiment, if 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 the end code block following the current start code block is the packet's end code block, but is also the second cell's end code block, where a true start code block indicates that the start code block is the packet's start code block and not the second cell's start code block, and a pseudo-end code block indicates that the end code block is the second cell's end code block and not the packet's end code block. For example, as shown in Figure 16, if the second preset value is represented by xxxx, and assuming the second preset value is in the 7th byte after the synchronization header in the start code block, then if the second preset value xxxx is 0x5A, it indicates that the current start code block is a true start code block, and the end code block following the current start code block is the packet's end code block, but is also the second cell's end code block. The second preset value may also be in other byte positions and may be other values, and is not particularly limited here.

[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, a packet start code block, or both a fragment start code block and a packet start code block. 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, a packet end code block, or both a fragment end code block and a packet end code block, and is not particularly limited here. For example, if the type of the last end code block of the current encoded fragment information is determined to be a fragment end code block and not a packet start code block, then the type of the end code block of the immediately preceding encoded fragment information may be determined to be a fragment end code block and not a packet end code block. The fragment code block type flag value may be set to any byte from the 2nd to the 8th 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, assuming that the fragment code block type flag value is "0xAA", it is used to indicate that the current start code block is a pseudo start code block, indicating that the start code block is a fragment start code block (i.e., the start code block of a true message) and not the packet start code block, and that the end code block immediately preceding the start code block (i.e., the type of the end code block of the preceding encoded fragment information) is a pseudo end code block, where the pseudo end code block indicates that the end code block of the preceding encoded fragment information is a fragment end code block and not the packet end code block.

[0073] In one embodiment, as shown in Figure 15, if the encoded fragment information uses a pseudo-start code block as the start code block, that is, if the start code block is not the packet start code block but a fragment start code block, the fragment code block type flag value may be set to "0xAA", and the fragment start code block may be generated by placing it in the 7th byte after the synchronization header of the fragment start code block, and the fragment start code block may be identified as a pseudo-start code block. When a second cell bearing the encoded fragment information is received, it may be determined that the fragment start code block is not the 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, or the fragment code block type flag value may be set to "0xFF", and the fragment start code block may be generated by placing it in the 8th byte after the synchronization header of the fragment start code block, and the fragment start code block may be identified 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 used to determine the type of the start code block of the current second cell, the type of the end code block of the previous 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, if the cell code block type flag value is a third preset value, then the cell code block type flag value indicates that the current start code block of the second cell is the start code block of the packet, is the start code block of the second cell, and the end code block following the current start code block of the second cell is a true end code block, where a 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. For example, as shown in Figure 16, the third preset value is represented by xxxx, and assuming that the third preset value is in the 7th byte after the synchronization header in the start code block of the second cell, if the third preset value xxxx is 0xF5, then the current start code block of the 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). Furthermore, the third preset value may be in other byte positions and may be other values, and is not particularly limited here.

[0076] In another embodiment, if the cell code block type flag value is the fourth preset value, the cell code block type flag value indicates that the current start code block of the second cell is the start code block of the packet, but is also the start code block of the second cell, and that the end code block following the current start code block of the second cell is a pseudo-end code block, where 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. For example, as shown in Figure 16, if the fourth preset value is represented by xxxx and the fourth preset value is the 7th byte after the synchronization header in the start code block of the second cell, then if the fourth preset value xxxx is 0xFA, it indicates that the current start code block of the 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 that the end code block following the current start code block of the second cell is a pseudo-end code block. The fourth preset value may also be at other byte positions and may be other values, and is not particularly limited here.

[0077] In another embodiment, if the cell code block type flag value is the fifth preset value, the cell code block type flag value indicates that the current start code block of the second cell is a pseudo start code block, and the end code block following the start code block of the second cell is a true end code block, where a 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 a packet, and a true end code block indicates that the end code block is the end code block of a packet and not the end code block of the second cell. For example, as shown in Figure 16, if the fifth preset value is represented by xxxx and the fifth preset value is located in the 7th byte after the synchronization header in the start code block of the second cell, then if the fifth preset value xxxx is 0xA5, it indicates that the current encoded code block is the start code block of the second cell and not the start code block of a packet (i.e., not the start code block of a client message), and the end code block following the start code block of the second cell is a true end code block. Furthermore, the fifth pre-set value may be located at other byte positions and may be any other value; it is not particularly limited here.

[0078] In another embodiment, if the cell code block type flag value is the sixth preset value, the cell code block type flag value indicates that the current start code block of the second cell is a pseudo start code block, and the end code block following the start code block of the current second cell is a pseudo end code block, where 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 a packet, and 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 a packet. For example, as shown in Figure 16, if the sixth preset value is represented by xxxx and the sixth preset value is the seventh byte after the synchronization header in the start code block of the second cell, then if the sixth preset value xxxx is 0xAA, then the current start code block of the second cell is simply the start code block of the second cell and not the start code block of a client message, and the subsequent end code block is also simply the end code block of the second cell and not the end code block of a packet (i.e., not the end code block of a client message). Furthermore, the sixth pre-set value may also be located at other byte positions and may be any other value; it is not particularly limited here.

[0079] The fragment code block type flag value may be any of the following values, and the meaning of each value may be the same as the meaning of the cell code block type flag value in the above embodiment, so an explanation is omitted here. Similarly, the message code block type flag value may also be any of the following values, and the meaning of each value may be the same as the meaning of the cell code block type flag value in the above embodiment, so an explanation is omitted here.

[0080] In one embodiment, since a pseudo-end code block of one second cell and a pseudo-start code block of the next second cell appear as a pair, by bearing a fragment sequence number to the start code block of the second cell corresponding to each encoded fragment information, it is possible to determine whether the current second cell is the second cell in which the last encoded fragment information is placed. If the current second cell is not the second cell in which the last 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 encoded fragment information, it may be determined that the first end code block immediately following 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 Figure 17, the fragment sequence number SQ is bearered in the 6th byte after the synchronization header of the start code block of the second cell, and the fragment sequence numbers SQ corresponding to each consecutive encoded fragment information may be set so that the fragment sequence number gradually decreases. In other words, the fragment sequence number SQ corresponding to each consecutive 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 in this case.

[0081] In one embodiment, as shown in Figure 18, packet 2 is fragmented and encoded to obtain four encoded fragment pieces, these four encoded fragment pieces are placed in the corresponding second cell, and then second traffic information (e.g., client traffic) at the location of the second cell is transmitted. Here, the fragment start code block of each of these four encoded fragment pieces contains a fragment sequence number SQ, and the fragment sequence numbers SQ corresponding to these four encoded fragment pieces are 3, 2, 1, and 0, respectively. The encoded fragment pieces with fragment sequence numbers SQ 2 and 1 correspond to the middle encoded code block of packet 2, and therefore, the fragment end code blocks in these encoded fragment pieces with fragment sequence numbers SQ 2 and 1 can be determined to be pseudo-end code blocks. Furthermore, the encoded fragment piece with fragment sequence number SQ 1 is the last encoded fragment piece corresponding to packet 2, and therefore, the first end code block immediately following the fragment start code block in this encoded fragment piece can be determined to be the true end code block, which is the end code block T' of packet 2.

[0082] Furthermore, the Ethernet 802.3br standard defines a method for interrupting lower-priority messages when messages with different priorities are transmitted simultaneously with a higher-priority message. For example, assuming that the priority of the second traffic information is lower than that of the first traffic information, and the second traffic information is being transmitted while the first traffic information needs to be transmitted, the transmission of the second traffic information will be interrupted or canceled, and the first traffic information will be transmitted beforehand or interrupting it. Regarding the encoded fragment information of the second traffic information whose transmission has been interrupted, the 802.3br standard shows a method for indicating each encoded fragment whose transmission has been interrupted, as shown in Figures 19 and 20. In Figure 19, for the first encoded fragment whose transmission has been interrupted, the content of the 8th byte of the fragment start code block of the encoded fragment information may be set to SMD-S, where SMD-S may be one of 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. In Figure 20, for other coded fragment information following the first coded fragment information, the content of the 7th byte of the fragment start code block of that coded 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, it is necessary to associate the SMD-S of the first coded fragment information with the SMD-C of other coded fragment information following the first coded fragment information; that is, if the fragment start code block of the first coded fragment information is set to SMD-S0, the fragment start code block of the subsequent other coded fragment information must be set to SMD-C0.If the fragment start code block of the first encoded fragment information is set with SMD-S1, the fragment start code blocks of subsequent encoded fragment information must be set with SMD-C1. If the fragment start code block of the first encoded fragment information is set with SMD-S2, the fragment start code blocks of subsequent encoded fragment information must be set with SMD-C2. If the fragment start code block of the first encoded fragment information is set with SMD-S3, the fragment start code blocks of subsequent encoded fragment information must be set with SMD-C3.

[0083] [Table 1]

[0084] [Table 2]

[0085] Furthermore, the field `frag_count`, corresponding to the 8th byte in the fragment start code block of subsequent coded fragment information after the first coded fragment information, may represent the sequential relationship of the subsequent coded fragment information to facilitate out-of-order detection. In some embodiments, as shown in Table 2, in addition to the first coded fragment information, the `frag_count` in the fragment start code blocks of the subsequent 1st to 4th coded fragment information are 0xE6, 0x4C, 0x7F, and 0xB3, respectively, and then the `frag_count` in the fragment start code blocks of the subsequent 5th to 8th coded fragment information are 0xE6, 0x4C, 0x7F, and 0xB3, respectively, and so on, and the explanation is omitted here as it repeats in this manner.

[0086] Based on the above analysis, in one embodiment, since multiple second traffic information is not fragmented and encoded simultaneously, only one set of SMD-S and SMD-C may be bearered to the fragment start code block of the encoded fragment information whose transmission was interrupted. For example, SMD-S0 is bearered to the fragment start code block of the first encoded fragment information, and SMD-C0 is bearered to the fragment start code block of subsequent encoded fragment information, where SMD-S0 indicates that the fragment start code block of the first encoded fragment information is a 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 subsequent encoded fragment information is a pseudo start code block, and is not particularly limited thereto.

[0087] In another embodiment, true termination code blocks or pseudo-termination code blocks may be defined in accordance with the 802.3br standard, for example, if the cyclic redundancy check (CRC) value of the second traffic information bearing the encoded fragment information is correct, the fragment termination code block of the encoded fragment information is a true termination code block, or if the recombination cyclic redundancy check (mCRC) value of the second traffic information bearing the encoded fragment information is correct, the fragment termination code block of the encoded fragment information is a pseudo-termination code block, and is not particularly limited herein.

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

[0089] For example, the process of placing a client message in the second cell involves extracting the client message bytes, encoding them according to a specific order and rule, and then placing them in the second cell. This rule is 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 client message start flag (preamble and frame delimiter byte), and the client message content is encoded to obtain the message start code block, then the start code block corresponding to the client message start flag is placed at the first code block position of the second cell, and at the same time, a cell code block type flag value indicating that this start code block is the client message start code block, even though it is the start code block of the second cell, may be included in this start code block. If, instead of the client message start flag content (preamble and frame delimiter byte), the client message byte content is placed at the first code block position of the second cell, 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 client message start code block, but merely the start code block of the second cell. Then, the client message byte content is sequentially placed at positions after the start code block of the second cell. Furthermore, 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, as well as whether the end code block following the current start code block of the 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 end code block of the second cell, the client message content is encoded, and the encoded code block of the client message is placed there.

[0092] Finally, at the location of the second cell's exit code block, i.e., the location of the last code block, if the client message code block to be placed is the last byte of the client message corresponding to the exit code block that encoded the content of the client message, then the exit code block that encoded the client message is placed at the location of the second cell's exit code block. If the client message content placed at the location of the second cell's start code block is not the last byte of the client message, then the encoded code block is not the client message's exit code block. In this case, the client message content bytes must be extracted, encoded into a pseudo-exit code block, and placed at the location of the second cell's exit code block. This indicates that the second cell's exit code block is not the client message's exit code block, i.e., it is not a true exit code block. Furthermore, whether an exit code block is a true exit code block or a pseudo-exit code block may be indicated by the pseudo-start code block that follows the exit 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, then the previous end code block is a pseudo-end code block. If the start code block following the end code block is a true start code block, then the previous end code block is a true end code block. In addition to forward indications, backward indications are 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 start code block of the previous second cell.

[0093] Furthermore, if the cell stream contains at least two adjacent second cells, these at least two adjacent second cells are treated as a single target cell, and the client message is placed at the location of the target cell. When placing the client message, both the location of the exit code block of the former second cell and the location of the start code block of the latter second cell are used for placing the client message.

[0094] In the process of placing client messages, if there are no client messages, a code block such as an idle code block, a pseudo-start code block, or a pseudo-end code block may be placed in place of the client messages.

[0095] Although the above placement method does not demonstrate a fragmentation process, it achieves the objective of fragmenting and placing client messages.

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

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

[0098] In one feasible embodiment, the cell position of each cell in the cell stream remains unchanged during the process of transmitting the cell stream. Alternatively, the cell position may be determined based on the time it takes for the cell to complete bearing the traffic information, and is not particularly limited thereto.

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

[0100] In one feasible embodiment, the cells in the cell stream may be a first cell, a second cell, or both a first and a second cell, and the cell structure of the first cell and the cell structure of the second cell may be the same, but are not particularly limited here.

[0101] In one feasible embodiment, the cell structure of a cell consists of multiple 66-bit code blocks, all defined by 64B / 66B coding rules, 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 the following is not limited: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. The cell start code block is the cell start flag, and the contents within the cell start code block can be filled according to the contents of the Ethernet message preamble and frame interval. The cell end code block is the cell end flag, and 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 the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. Similarly, the last few bytes of the exit code block may bear at least one of the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. For example, the last seven bytes in T7 may bear seven bytes of overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. As shown in Figure 5, each unfilled cell represents a byte position that can be used to fill at least one of the following: an overhead field, instructional information indicating the order relationship between cells, traffic type information, or fault instruction information. Also, as shown in Figure 6, both the first and second cells contain sequence numbers 1, 2, ..., X (where X is a positive integer), and these sequence numbers appear cyclically from 1 to X. These sequence numbers may, but are not limited to, be used to determine the position of each cell.

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

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

[0104] In one feasible embodiment, the first and second cells have the same length, and both the first and second cells 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 consist 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 employing a traffic information processing method including steps S410 to S430 described above, the cell structure and cell location of each cell in the cell stream can be determined. Then, based on the cell structure, cell location, and first traffic information, the first cell in the cell stream can be determined, and based on the cell structure, cell location, and second traffic information, the second cell in the cell stream can be determined.

[0106] As an example, in a scenario where a client message is fragmented and encoded while transmitting a second cell, if the start code block S' of the first packet of the first client message is placed in the cell start code block S''' of the first second cell at the cell location, and if fragment encoding of the client message is not complete at the last code block location of the second cell, then the cell end code block T''' is directly obtained by encoding at the last code block location of the second cell, and the second cell is transmitted. Subsequently, the 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 is continued. Therefore, in this embodiment, by adopting this method, the first block location at each cell location is always the cell start code block S''', and the last code block location at the cell location is always the cell end code block T'''.

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

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

[0109] Step S520: Determine the number of first cells to bear the first traffic information based on the number and bandwidth of the first traffic information.

[0110] Step S530: Determine the first cell in the cell stream based on the cell structure, cell location, and number of first cells.

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

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

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

[0114] Step S620: Determine the number of second cells to bear the second traffic information based on the number and bandwidth of the second traffic information.

[0115] Step S630: Determine the second cell in the cell stream based on the cell structure, cell location, and number of second cells.

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

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

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

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

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

[0121] In one feasible embodiment, the third traffic information may be beared to the third cell by mapping, and the fourth traffic information may be beared to the location of the fourth cell by placement, but this is not particularly limited here.

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

[0123] In one feasible embodiment, the cell structure of the third cell may be the same as that of the first cell, and this will not be explained here.

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

[0125] In one feasible embodiment, the cell structure of the fourth cell may be the same as that of the second cell, and this will not be explained here.

[0126] In this embodiment, by employing a traffic information processing method including steps S710 to S740 described above, the target cell stream is first received, then the third cell that bears the third traffic information and the fourth cell that bears the fourth traffic information in the target cell stream 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, step S740 will be further described as shown in Figure 28, but this step S740 may include, but is not limited to, steps S810 and S820.

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

[0129] Step S820: In the fourth cell, the pseudo-start code block and pseudo-end code block are removed to obtain the fourth traffic information.

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

[0131] Note that in all of the above embodiments, the format of the start code block, the format of the true start code block, and the format of the pseudo start code block all include the S code block format or other format types defined in the 802.3 protocol. 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 include the T code block format or other format types defined in the 802.3 protocol.

[0132] Referring to Figure 29, one embodiment of the present invention 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 memory 202 may be connected by a bus or by other means.

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

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

[0136] The embodiments of the equipment described above are merely schematic, and the units described as separate components may or may not be physically separated. That is, they may be located in one place or distributed across multiple network elements. Some or all of these modules may be selected as needed to achieve the objectives of the embodiments of this embodiment.

[0137] Furthermore, one embodiment of the present invention further provides a computer-readable storage medium storing computer-executable instructions, and when the computer-executable instructions are executed by a processor or controller, for example, steps S110-S120 of the method in Figure 2, steps S210-S220 of the method in Figure 7, steps S310-S320 of the method in Figure 10, steps S410-S430 of the method in Figure 21, steps S510-S530 of the method in Figure 25, steps S610-S630 of the method in Figure 26, steps S710-S740 of the method in Figure 27, and steps S810-S820 of the method in Figure 28 are executed.

[0138] Furthermore, one embodiment of the present invention provides a computer program product including a computer program or computer instruction stored on a computer-readable storage medium, and the processor of the computer device reads the computer program or computer instruction from the computer-readable storage medium and, upon executing the computer program or computer instruction, causes the computer device to execute the traffic information processing method in the above embodiment, for example, steps S110 to S120 of the method in Figure 2, steps S210 to S220 of the method in Figure 7, steps S310 to S320 of the method in Figure 10, steps S410 to S430 of the method in Figure 21, steps S510 to S530 of the method in Figure 25, steps S610 to S630 of the method in Figure 26, steps S710 to S740 of the method in Figure 27, and steps S810 to S820 of the method in Figure 28.

[0139] In the embodiment of the present invention, by placing 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 process of bearing the second traffic information to the cell in a mapping manner is omitted. Therefore, the mapping process can be simplified, which not only improves bearer efficiency but also improves bandwidth utilization.

[0140] All or part of the steps in the methods disclosed above, the system may be implemented as software, firmware, hardware, or a suitable combination thereof. Some or all of the physical components may be implemented as software executed by a processor such as a central processor, a digital signal processor, or a 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-temporary media) and communication media (or temporary media). As is well 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 technique for storing information (e.g., computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, magnetic cartridges, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media may include any information distribution medium, typically containing computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms.

Claims

1. A method for processing traffic information, The steps include mapping first traffic information to a first cell and transmitting the first cell, The steps include: fragmenting and encoding each packet of second traffic information, which contains at least one packet, to obtain a plurality of encoded code blocks; The steps include: assembling multiple coded code blocks according to a predetermined rule to obtain multiple coded fragment information; A step of placing each of the encoded fragment information into each second cell, wherein a pseudo-start code block or the start code block of the target packet is placed at the position of the start code block of the second cell, a pseudo-end code block or the end code block of the target packet is placed at the position of 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. A method comprising the step of transmitting the second cell.

2. The length of each of the encoded fragment pieces is equal to the length of the second cell. or, The method according to claim 1, wherein the lengths of at least two adjacent coded fragments among the plurality of coded fragments are not equal to the length of the second cell, and the sum of the lengths of the at least two adjacent coded fragments is equal to an integer multiple of the length of the second cell.

3. The aforementioned pre-set rules are: The same coded fragment information includes the same coded code block of the packet, or The same coded fragment information includes the coded code blocks of multiple packets, or The same coded fragment information includes the target code block assembly block and the coded code block of the packet, or The method according to claim 1, wherein the same encoded fragment information includes at least one of the following: a target code block assembly block.

4. The method according to claim 1, wherein the start code block of the packet includes 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 preceding packet, and the type of the end code block after the start code block of the current packet.

5. If 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 that the end code block following the current start code block is a true end code block; 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; and 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. or, The method according to claim 4, 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 the end code block following the current start code block is the end code block of the packet but is also the end code block of the second cell, and 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.

6. The method according to claim 1, wherein the start code block of the second cell includes a cell code block type flag value for determining the type of the current start code block of the second cell, the type of the previous end code block of the second cell, and the type of the end code block after the current start code block of the second cell.

7. If the cell code block type flag value is a third preset value, the cell code block type flag value indicates that the current start code block of the second cell is the start code block of the packet, and that the end code block following the current start code block of the second cell is a true end code block, and that the true end code block is not the end code block of the second cell, but the end code block of the packet. or, If the cell code block type flag value is a fourth preset value, the cell code block type flag value indicates that the current start code block of the second cell is the start code block of the packet, and that the end code block following the current start code block of the second cell is the pseudo-end code block. or, If the cell code block type flag value is a fifth preset value, the cell code block type flag value indicates that the current start code block of the second cell is the pseudo start code block, and the end code block following the start code block of the second cell is the 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, The method according to claim 6, wherein, when the cell code block type flag value is a sixth preset value, the cell code block type flag value indicates that the current start code block of the second cell is the pseudo start code block, and the end code block following the start code block of the second cell is the pseudo end code block.

8. A method for processing traffic information, The steps include mapping first traffic information to a first cell and transmitting the first cell, The steps include encoding the second traffic information to obtain the encoded second traffic information, If the cell stream includes at least two adjacent second cells, the step of making the at least two adjacent second cells a single target cell, The steps include: placing a pseudo-start code block or a true start code block at the start code block position of each of the second cells among the target cells; placing a pseudo-end code block or a true end code block at the end code block position of each of the second cells; and placing the encoded second traffic information at the position between the start code block and the end code block of each of the second cells, wherein the true start code block indicates that the start code block is the start code block of a 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. A method comprising the step of transmitting the second cell.

9. The method according to claim 8, wherein the true start code block is located at the position of the start code block of the first second cell among the target cells, the pseudo start code block is located at the position of the start code block of any cell other than the first second cell among the target cells, the true end code block is located at the position of the end code block of the last second cell among the target cells, and the pseudo end code block is located at the position of the end code block of any cell other than the last second cell among the target cells.

10. A step of determining the cell structure and cell position of each cell in a cell stream, wherein the cell structure consists of a cell start code block, a cell data code block, and a cell end code block, A step of determining the first cell in the cell stream based on the cell structure, the cell location, and the first traffic information, The method further includes the step of determining the second cell in the cell stream based on the cell structure, the cell location, and the second traffic information, The method according to claim 1 or 8, wherein the cell position in the cell stream remains unchanged.

11. The step of determining the first cell in the cell stream based on the cell structure, the cell location, and the first traffic information is: The steps include determining the number and bandwidth of the first traffic information, A step of determining the number of first cells for bearing the first traffic information based on the number and bandwidth of the first traffic information, The method according to claim 10, comprising the step of determining the first cell in the cell stream based on the cell structure, the cell position and the number of first cells.

12. The step of determining the second cell in the cell stream based on the cell structure, the cell location, and the second traffic information is: The steps include determining the number and bandwidth of the second traffic information, A step of determining the number of second cells for bearing the second traffic information based on the number and bandwidth of the second traffic information, The method according to claim 10, comprising the step of determining the second cell in the cell stream based on the cell structure, the cell position and the number of the second cell.

13. The steps include receiving the target cell stream and The steps include determining the third cell that bears the third traffic information and the fourth cell that bears the fourth traffic information in the target cell stream, The steps include extracting the third traffic information from the third cell, The method according to claim 1 or 8, further comprising the step of extracting the fourth traffic information from the fourth cell.

14. A network device comprising 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 method according to any one of claims 1 to 9.

15. A computer-readable storage medium storing computer-executable instructions for performing the method according to any one of claims 1 to 9.

Images