Message sending method, communication device and storage medium

Abstract

The embodiments of the present application provide a message sending method, a communication device and a storage medium. The message sending method comprises: acquiring an Ethernet message that has been subjected to data encoding, wherein the Ethernet message comprises a plurality of target bit code blocks; mapping the plurality of target bit code blocks to a bearer frame, wherein the bearer frame comprises a first payload area and an OMFI field, and a second payload area is configured in the OMFI field, such that the number of bits of the first payload area and the second payload area is an integer multiple of the number of bits of the target bit code blocks; and mapping the bearer frame to an OTN frame, and sending the OTN frame.

Description

Message sending method, communication device and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the Chinese patent application with application number 202311281156.7 and application date September 26, 2023, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby introduced into this application as a reference. Technical Field

[0003] The embodiments of the present application relate to the field of communication technology, and in particular to a message sending method, communication equipment, and storage medium. Background Art

[0004] Communication networks are the highways of the information age. In the past, communications primarily focused on voice services, and communication networks using SDH (Synchronous Digital Hierarchy) and OTN (Optical Transport Network) technologies effectively met the needs of voice delivery. In related technologies, OTN networks carry customer services via defined containers such as ODU (Optical Data Unit) 0, ODU1, ODU2, ODU3, and ODU4. These services are carried at speeds of 1.25G, 2.5G, 10G, and 40G, respectively, with the minimum speed being 1.25G. Customer services with speeds below 1.25G are considered low-speed services. However, Ethernet packets in low-speed customer services require 11 bearer frames to carry an integer number of 66-bit blocks within an OTN network. These 11 bearer frames result in a wide variety of 66-bit block boundary locations, making block mapping and demapping complex and costly.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a message sending method, a communication device, and a storage medium, which can simplify code block mapping and demapping and achieve low implementation costs.

[0007] In a first aspect, an embodiment of the present application provides a message sending method, including:

[0008] Acquire a data-encoded Ethernet message, wherein the Ethernet message includes a plurality of target bit code blocks;

[0009] Mapping the multiple target bit code blocks to a bearer frame, wherein the bearer frame includes a first payload area and an OMFI field, wherein the OMFI field is configured with a second payload area, such that the number of bits of the first payload area and the second payload area is an integer multiple of the number of bits of the target bit code block;

[0010] The bearer frame is mapped to an OTN frame, and the OTN frame is sent.

[0011] In a second aspect, an embodiment of the present application further provides a communication device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the message sending method as described in the first aspect is implemented.

[0012] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the message sending method as described in the first aspect.

[0013] According to the message sending method, communication device and storage medium provided by the embodiments of the present application, the message sending method of one embodiment includes: obtaining a data-encoded Ethernet message, the Ethernet message including multiple target bit code blocks; mapping the multiple target bit code blocks to a bearer frame, wherein the bearer frame includes a first payload area and an OMFI field, and the OMFI field is configured with a second payload area, so that the number of bits in the first payload area and the second payload area is an integer multiple of the number of bits of the target bit code block; mapping the bearer frame to an OTN frame, and sending the OTN frame. In the above embodiment, multiple target bit code blocks of the Ethernet message are mapped to the bearer frame. Since the OMFI field in the bearer frame is configured as a newly added second payload area, and the total number of bits of the original first payload area and the newly added second payload area is an integer multiple of the number of bits of the target bit code block, the container position of this part of the second payload area is added to the bearer frame, so that the number of bits of all payload areas of a bearer frame is just an integer multiple of the number of bits of the target bit code block. Therefore, only one bearer frame is needed to carry an integer number of target bit code blocks, which not only facilitates the carrying and transmission of Ethernet messages, but also facilitates the mapping and demapping of code blocks. Therefore, the embodiment of the present application can simplify the mapping and demapping of code blocks and achieve low implementation cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a schematic diagram of the OTN frame structure;

[0015] FIG2 is a schematic diagram of the structure of the OTN frame switching time slot;

[0016] Figure 3 is a schematic diagram of the fgOTN frame structure;

[0017] Figure 4 is a schematic diagram of customer services mapped through fgOTN frames and then transmitted through OTN frames;

[0018] FIG5 is a schematic diagram of the 66 encoding process of Ethernet messages;

[0019] Figure 6 is a block diagram of 66 encoding rules;

[0020] Figure 7 is a diagram of the OMFI field locations;

[0021] FIG8 is a schematic diagram of the OMFI field indicating the 66-bit mapping process;

[0022] FIG9 is a flowchart of a message sending method provided by an embodiment of the present application;

[0023] Figure 10 is a schematic diagram of the fgOTN frame container structure;

[0024] FIG11 is a schematic diagram of byte position distribution of 30 data bits in a second payload area provided by one embodiment of the present application;

[0025] FIG12 is a schematic diagram of byte position distribution of 30 data bits in a second payload area provided by an embodiment of the present application;

[0026] FIG13 is a schematic diagram of byte position distribution of 30 data bits in a second payload area provided by one embodiment of the present application;

[0027] FIG14 is a schematic diagram showing the byte positions of 30 data bits in the second payload area provided by one embodiment of the present application;

[0028] FIG15 is a schematic diagram showing the byte positions of 30 data bits in the second payload area provided by one embodiment of the present application;

[0029] FIG16 is a schematic diagram showing the byte positions of 30 data bits in the second payload area provided by one embodiment of the present application;

[0030] FIG17 is a schematic diagram of byte position distribution of 30 data bits in a second payload area provided by one embodiment of the present application;

[0031] FIG18 is a schematic diagram of byte position distribution of 30 data bits in a second payload area provided by one embodiment of the present application;

[0032] FIG19 is a flowchart of step S102 in FIG9 provided in one embodiment of the present application;

[0033] FIG20 is a schematic diagram of separating the synchronization header and data bytes of a 66-bit code block;

[0034] FIG21 is a schematic diagram showing the mapping of synchronization headers and data bytes of a 66-bit code block;

[0035] FIG22 is a flowchart of step S201 in FIG19 provided in one embodiment of the present application;

[0036] Figure 23 is a schematic diagram of a communication device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0038] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts depict logical sequences, in some cases, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, used in the specification, claims, and accompanying figures, are used to distinguish similar items and are not necessarily intended to describe a specific sequence or precedence.

[0039] In the embodiments of the present application, words such as "further," "exemplarily," or "optionally" are used to indicate examples, illustrations, or descriptions and should not be interpreted as being more preferred or advantageous over other embodiments or designs. The use of words such as "further," "exemplarily," or "optionally" is intended to present related concepts in a concrete manner.

[0040] In order to more conveniently describe the working principle of the embodiments of the present application later, an introduction to the relevant technical scenarios is given below.

[0041] Communication networks are the highways of the information age. In the past, communications primarily focused on voice services, and communication networks using SDH and OTN technologies effectively met the needs of voice service delivery. OTN networks carry customer services via defined containers such as ODU0, ODU1, ODU2, ODU3, and ODU4. These services are carried at speeds of 1.25G, 2.5G, 10G, and 40G, respectively, with a minimum speed of 1.25G. A method for efficiently and conveniently carrying customer services less than 1.25G within traditional OTN frames is needed. Low-speed customer services, as described in this application, refer to customer services with speeds below 1.25G.

[0042] OTN communication equipment is based on the G.709 protocol standard. The OTN process for delivering customer services is as follows: Customer services are first mapped into an optical payload unit (OPU), which is then mapped into an optical data unit (ODU), which is finally mapped into an OTN frame for transmission. Figure 1 shows the OTN frame structure, which consists of 4 x 3824 bytes (4 rows, 3824 columns). In the figure, OPU OH (OPU overhead) is the OPU overhead field, located in columns 16 and 17 of the OTN frame; ODU OH (ODU overhead) is the ODU overhead field; OTU OH (OTU overhead) is the OTU overhead field; and alignm is the frame header alignment marker. Customer services are loaded and delivered in the OPU, which is the payload area of ​​the OTN frame. The OTN frame payload area is located in columns 18-3824 of the frame. The area from bytes 17 to 3284 in the figure is the bearer area (or payload area) of the OTN frame. The bearer area of ​​the OTN frame is divided into time slots, each of which is 16 bytes. Each row in the bearer area of ​​the OTN frame contains 3824-16 = 3808 bytes, resulting in 238 time slots. A four-row bearer area provides 952 time slots, as shown in Figure 2. Each time slot is 16 bytes long, and the service speed associated with each time slot is 10 Mbps (actually slightly higher than 10 Mbps, after deducting various overheads to ensure that the customer service speed reaches 10 Mbps). For a 10 Mbps customer service, the customer service is first mapped into a subframe or basic frame, then a timeslot is selected in the OTN frame for carriage. Each timeslot carries 16 bytes of the subframe or basic frame content. After multiple transmissions, all bytes of the basic frame are carried. In actual applications, customer services are not directly carried in timeslots. Instead, they are first mapped into bearer frames, which are then mapped into timeslots for carriage. International standards define the specific structure of the bearer frame, called the fgOTN frame, also known as the basic frame. Figure 3 shows the basic frame structure. It consists of 4 rows and 3824 columns, with each row containing 3824 bytes. Columns 1-16 and 1905-1920 are overhead, while the remaining columns carry customer services. When carrying customer services, the services are mapped into the fgOTN frame, which is then transmitted as customer service content within the OTN frame, as shown in Figure 4. At the receiving end, the fgOTN frame bytes are extracted from the corresponding bearer timeslot in the OTN, the fgOTN frame structure is restored, and the customer services are then extracted and restored from the fgOTN frame.

[0043] Before Ethernet services are mapped into fgOTN frames, they must first be encoded using 64 / 66 encoding. As shown in Figure 5, two bits are added to every eight bytes of customer content (a total of 64 bits) to expand the information block into a 66-bit information block. The two additional bits are placed at the beginning of the 66-bit block (these two bits are fixed to "01" or "11"; "01" indicates that the information block is a data block, and "11" indicates that the information block is a control block). The synchronization header bit is placed at the beginning of the block. After the eight bytes of 64-bit content are converted into a 66-bit block, they are mapped into the fgOTN frame for transport. At the receiving end, the 66-bit information block is extracted and identified from the fgOTN, and the original eight bytes (64 bits of data) of customer service are recovered from the 66-bit information block to reassemble the customer message. Figure 6 shows the 64 / 66 encoding rules of the Ethernet 802.3 protocol. Each block consists of 66 bytes. The first two bits are the synchronization header. A synchronization header bit of "01" indicates a D block (data block). The following 8 bytes (64 bits) contain 8 bytes of data. A synchronization header bit of "10" indicates a control block. The first byte following indicates the control block type, followed by the next 7 bytes containing the control block's content. The contents of these 7 bytes are determined by the control block type, as shown in Figure 6. Both S blocks and T blocks are control blocks. The first byte of an S block is 0x78, indicating that the control block is an S block. In addition to indicating the end of a block, a T block can also carry client bytes (located in the last 7 bytes of the block). In the Ethernet standard, there are 8 types of T code blocks: T0, T1, T2, T3, T4, T5, T6, and T7. The T0 code block (the first byte is 0x87) does not carry customer information, the T1 code block (the first byte is 0x99) carries 1 byte of customer information, the T2 code block (the first byte is 0xAA) carries 2 bytes of customer information, and so on. The T7 code block (the first byte is 0xFF) carries 7 bytes of customer information.

[0044] After 64 / 66 encoding, each Ethernet message becomes a 66-bit block stream, consisting of an S block, several D blocks, and a T block. Since each block is 66 bits long, and the fgOTN payload area consists of many bytes, each fgOTN payload area has 121,344 bits. Since 121,344 is not a multiple of 66, the position of the 66-bit block boundaries in the fgOTN frame cannot be fixed. To indicate the 66-bit block boundaries, as shown in Figure 7, the OMFI field is set in columns 16 and 1920 of the fgOTN frame overhead field to determine the 66-bit block boundaries in the fgOTN frame. The specific principle is as follows: As shown in Figure 8, the payload area of ​​the first fgOTN frame can carry 1838 66-bit blocks and the 36 bits from one block. The remaining 66-36 = 30 bits of this block are carried in the second fgOTN frame (one block is split across two frames), which then carries the following 66-bit blocks. After carrying 1838 66-bit blocks in the second fgOTN frame, the remaining space can only carry the 6 bits from one block. The third fgOTN frame carries the same information, first carrying the 66-6 = 60 bits of the previous block, then continuing with the 66-bit blocks, and finally carrying the remaining bits that fall short of a block. The fourth, fifth, ..., tenth frames follow the same pattern, until the eleventh fgOTN frame, which carries a complete 66-bit block. Eleven fgOTN frames can carry an integer number of 66-bit code blocks. The OMFI field is used to determine the order of the 11 fgOTN frames. The OMFI field in the first fgOTN frame contains all 0s, the OMFI field in the second fgOTN frame contains all 1s, the OMFI field in the third fgOTN frame contains all 2s, and so on. The OMFI field in the tenth fgOTN frame contains all 9s, and the OMFI field in the eleventh fgOTN frame contains all 10s. The OMFI field content can be used to determine the order of fgOTN frames and, therefore, the boundary positions of the 66-bit code blocks within the frame.

[0045] Using the OMFI field content to determine the order of fgOTN frames and, in turn, the 66-bit block boundaries is a feasible implementation method. However, this method is complex and requires determining the OMFI field content and then the 66-bit block boundary locations. The 11 fgOTN frames have a wide variety of block boundary locations, making block mapping and demapping complex and costly.

[0046] Based on this, the present application provides a message sending method, communication device, and storage medium. The message sending method in one embodiment includes: obtaining a data-encoded Ethernet message, the Ethernet message including multiple target bit code blocks; mapping the multiple target bit code blocks to a bearer frame, wherein the bearer frame includes a first payload area and an OMFI field, the OMFI field being configured with a second payload area such that the number of bits in the first payload area and the second payload area is an integer multiple of the number of bits in the target bit code block; mapping the bearer frame to an OTN frame, and sending the OTN frame. In the above embodiment, multiple target bit code blocks of the Ethernet message are mapped to the bearer frame. Since the OMFI field in the bearer frame is configured as a newly added second payload area, and the total number of bits of the original first payload area and the newly added second payload area is an integer multiple of the number of bits of the target bit code block, the container position of this part of the second payload area is added to the bearer frame, so that the number of bits of all payload areas of a bearer frame is just an integer multiple of the number of bits of the target bit code block. Therefore, only one bearer frame is needed to carry an integer number of target bit code blocks, which not only facilitates the carrying and transmission of Ethernet messages, but also facilitates the mapping and demapping of code blocks. Therefore, the embodiment of the present application can simplify the mapping and demapping of code blocks and achieve low implementation cost.

[0047] The embodiments of the present application are further described below with reference to the accompanying drawings.

[0048] As shown in FIG9 , FIG9 is a flowchart of a message sending method provided by an embodiment of the present application. The message sending method may include but is not limited to steps S101 to S103 .

[0049] Step S101: Acquire a data-encoded Ethernet message, where the Ethernet message includes a plurality of target bit code blocks.

[0050] Step S102: Map multiple target bit code blocks to a carrier frame, wherein the carrier frame includes a first payload area and an OMFI field, and the OMFI field is configured with a second payload area, so that the number of bits in the first payload area and the second payload area is an integer multiple of the number of bits of the target bit code block.

[0051] Step S103: Map the bearer frame to an OTN frame, and send the OTN frame.

[0052] In this step, a data-encoded Ethernet message is obtained, and multiple target bit blocks in the Ethernet message are mapped to a bearer frame. Since the OMFI field in the bearer frame is configured as a newly added second payload area, and the total number of bits in the original first payload area and the newly added second payload area is an integer multiple of the number of bits in the target bit block, the bearer frame is then mapped to an OTN frame and transmitted. Thus, by adding the container position for the second payload area to the bearer frame, the total number of bits in the payload area of ​​a bearer frame is an integer multiple of the number of bits in the target bit block. Consequently, only one bearer frame is required to carry an integer number of target bit blocks, facilitating not only the carrying and transmission of Ethernet messages but also the mapping and demapping of code blocks. This simplifies code block mapping and demapping, reducing implementation costs.

[0053] In one embodiment, the bearer frame is an fgOTN frame having 4 rows and 3824 columns. Each column of each row contains 1 byte, and each byte has 8 bits. As shown in Figure 7 , columns 17 to 1904 and columns 1921 to 3824 of the fgOTN frame constitute the first payload area. Columns 16 and 1920 of the fgOTN frame constitute the OMFI field. As shown in Figure 10 , the OMFI field in column 16 has 8 bits per byte in each row, and the OMFI field in column 16 also has 8 bits per byte in each row. Therefore, the number of bits in the first payload area of ​​the fgOTN frame is 60416 + 60928 = 121344. Remove the original indication function of the OMFI field, and change the 16th and 1920th columns to the payload area function, that is, obtain the second payload area. The newly added second payload area has two columns with a total of 8*8=64 bits. Then, on the basis of the original first payload area, the newly added second payload area is added, and the total payload area has 121344+64=121408 bits.

[0054] In one embodiment, the second payload area includes multiple data bits, 30 of which are used to carry partial bits of a target bit block. For example, if the target bit block is a 66-bit block, 30 of the newly added 64 bits can be used to carry customer services. These 30 bits are used to carry partial bits of the 66-bit block, while the remaining 34 bits are fixed insertion bits and do not carry customer services. Consequently, the payload area in the fgOTN that effectively carries customer services has a total of 121,344 + 30 = 121,374 bits, which is sufficient to carry 1,839 66-bit blocks. In this case, the boundaries of the 66-bit blocks are fixed within each fgOTN frame, facilitating block mapping and simplifying circuit design.

[0055] In one embodiment, the OMFI field includes data bits located in columns 16 and 1920 of the frame. In one implementation, eight bytes can be added to columns 16 and 1920 of each row in each fgOTN frame, for a total of 64 bits. To carry a 66-bit code block, only 30 bits are required, leaving the remaining 36 bits reserved. This reduces the total payload area of ​​the fgOTN frame to 121,344 + 30 = 121,374 bits for carrying 66-bit code blocks.

[0056] It should be noted that the specific positions of the 30 data bits in the second payload area can be distributed in various ways. Since the data bits of at least one of the 16th column and the 1920th column are configured as the second payload area, only the data bits of the 16th column can be configured as the second payload area, that is, only the 16th column can be provided with 30 data bits; only the data bits of the 1920th column can be configured as the second payload area, that is, only the 1920th column can be provided with 30 data bits; or a total of 30 data bits can be provided from both the 16th column and the 1920th column.

[0057] In one embodiment, the second payload area may include multiple byte positions, and the 30 data bits in the second payload area may be allocated to the multiple byte positions. For example, 24 data bits in the second payload area may be allocated to three byte positions that can provide 8 data bits, while the remaining 6 data bits may be allocated to one byte position that can provide 6 data bits. For another example, 16 data bits in the second payload area may be allocated to two byte positions that can provide 8 data bits, while the remaining 14 data bits may be allocated to two byte positions that can provide 7 data bits. It can be seen that the number of data bits allocated to each byte position may be an odd number or an even number. It should be noted that when the number of data bits allocated to each byte position is even, since the synchronization header of a 66-bit code block is 2 bits, the synchronization header of the 66-bit code block can be stored exactly in the byte position of the second payload area. For example, the synchronization header of one 66-bit code block can be stored in a byte position that can provide 2 data bits, the synchronization headers of two 66-bit code blocks can be stored in a byte position that can provide 4 data bits, the synchronization headers of three 66-bit code blocks can be stored in a byte position that can provide 6 data bits, and the synchronization headers of four 66-bit code blocks can be stored in a byte position that can provide 8 data bits.

[0058] In one embodiment, as shown in FIG11 , the 30 data bits in the second payload area may be distributed in the following byte positions: 6 bits are provided at the 16th column of the first row (6 of the 8 bits at this byte position function as the payload area, and the other 2 bits are unused); 8 bits are provided at the 1920th column of the first row (all 8 bits at this byte position function as the payload area). 8 bits are provided at the 16th column and the 1920th column of the second row (all 8 bits at this byte position function as the payload area). Columns 16 and 1920 of the third to fourth rows are reserved and unused.

[0059] In one embodiment, as shown in FIG12 , the 30 data bits in the second payload area may be distributed in byte positions as follows: 6 bits are provided in the 16th column of the first row (8 bits in this byte position function as the payload area, and the remaining bit is unused). 8 bits are provided in the 16th columns of the second to fourth rows (all 8 bits in this byte position function as the payload area). Columns 1920 of the first to fourth rows are reserved and unused.

[0060] In one embodiment, as shown in FIG13 , the 30 data bits in the second payload area may be distributed in the following byte positions: 7 bits are provided at the 16th column of the first row and the 1920th byte position (7 of the 8 bits at this byte position function as the payload area, and the remaining bit is unused). 8 bits are provided at the 16th column of the second row and the 1920th column (all 8 bits at this byte position function as the payload area). The 16th column of the third and fourth rows, as well as the 1920th column of the third and fourth rows, are both reserved and unused.

[0061] In one embodiment, as shown in FIG14 , the 30 data bits in the second payload area may be distributed in byte positions as follows: 7 bits are provided at the 16th column of the first and second rows (7 of the 8 bits at this byte position function as the payload area, and the remaining bit is unused). 8 bits are provided at the 16th column of the third and fourth rows (all 8 bits at this byte position function as the payload area). Columns 1920 of the first through fourth rows are reserved and unused.

[0062] In one embodiment, as shown in FIG15 , the 30 data bits in the second payload area may be distributed in byte positions as follows: 7 bits are provided at the 16th column of the first and third rows (7 of the 8 bits at this byte position function as the payload area, and the remaining bit is unused). 8 bits are provided at the 16th column of the second and fourth rows (all 8 bits at this byte position function as the payload area). Columns 1920 of the first through fourth rows are reserved and unused.

[0063] In one embodiment, as shown in FIG16 , the 30 data bits in the second payload area may be distributed in the following byte positions: 3 bits are provided at the 1920th byte position in the first row, 16th column (3 of the 8 bits at this byte position function as the payload area, and the other 5 bits are not used). 4 bits are provided at the 1920th byte position in the 16th column in the second to fourth rows (4 of the 8 bits at this byte position function as the payload area, and the other 4 bits are not used).

[0064] In one embodiment, as shown in FIG17 , the 30 data bits in the second payload area may be distributed in the following byte positions: 3 bits are provided at the byte position of the 16th column of the first and second rows (3 of the 8 bits at this byte position function as the payload area, and the remaining 5 bits are not used). 4 bits are provided at the byte position of the 1920th column of the first and second rows (4 of the 8 bits at this byte position function as the payload area, and the remaining 4 bits are not used). 4 bits are provided at the byte positions of the 16th and 1920th columns of the third and fourth rows (4 of the 8 bits at this byte position function as the payload area, and the remaining 4 bits are not used).

[0065] In one embodiment, as shown in FIG18 , the 30 data bits in the second payload area may be distributed in the following byte positions: 3 bits are provided at the 16th column of the first and third rows (3 of the 8 bits at this byte position function as the payload area, and the remaining 5 bits are not used). 4 bits are provided at the 1920th column of the first and third rows (4 of the 8 bits at this byte position function as the payload area, and the remaining 4 bits are not used). 4 bits are provided at the 16th and 1920th columns of the second and fourth rows (4 of the 8 bits at this byte position function as the payload area, and the remaining 4 bits are not used).

[0066] It should be noted that the above are only a few embodiments of providing 30-bit positions in the 64-bit positions in the 16th column and the 1920th column as a payload area to carry a 66-bit code block. In actual use, there may be various other distributed embodiments, and this application does not make any specific limitations on this.

[0067] By providing 30 bits in the 16th and 1920th columns as the payload area to carry 66-bit code blocks, an fgOTN frame can carry 1839 66-bit code blocks, with each frame carrying an integer number of 66-bit code blocks, thereby simplifying the complexity of code block mapping and demapping and reducing costs.

[0068] When the payload area in each bearer frame, which effectively carries 66-bit code blocks, is an integer multiple of 66, each bearer frame can carry exactly 1839 66-bit code blocks, facilitating mapping and demapping. However, since each code block is 66 bits long, and the payload area in the bearer frame consists of many bytes, each byte is 8 bits long, and 8 bits is not a factor of 66 bits, each 66-bit code block needs to span multiple bytes when mapped to bytes. Furthermore, the starting position of the 66-bit code block is different in each byte, which still brings certain inconveniences to mapping and demapping.

[0069] In order to further facilitate mapping and demapping, on the basis of the above, the target bit code block includes a synchronization header and data bytes, and the synchronization header and data bytes of the target bit code block can be separated. The carrying frame includes a synchronization header area and a code block byte area. The synchronization header is carried in the synchronization header area, and the data bytes are carried in the code block byte area.

[0070] As shown in FIG. 19 , an embodiment of the present application illustrates step S102 , which includes but is not limited to steps S201 to S203 .

[0071] Step S201: Separate the synchronization headers and data bytes of multiple target bit code blocks.

[0072] Step S201: Aggregate multiple synchronization headers to obtain a synchronization header set, and aggregate multiple data bytes to obtain a data byte set.

[0073] Step S203: Map the synchronization header set to the synchronization header area, and map the data byte set to the code block byte area.

[0074] In this step, as shown in FIG20 , taking the target bit code block as a 66-bit code block as an example, the synchronization header portion and the data byte portion of the 66-bit code block can be separated, and then multiple synchronization headers are aggregated to obtain a synchronization header set, and multiple data bytes are aggregated to obtain a data byte set. The synchronization header set is then mapped to the synchronization header area, and the data byte set is mapped to the code block byte area. For a 66-bit code block, each 66-bit code block has 2 synchronization header bits. The 2-bit synchronization headers of 4 66-bit code blocks can be separated and concentrated for carrying. After the synchronization header bits and data byte bits are separated, since the length of the data byte portion is 64 bits, which is 8 bytes in length, a 66-bit code block can be mapped exactly into 8 bytes, further facilitating mapping and demapping. The 2-bit synchronization headers of 4 66-bit code blocks have a total of 8 bits, which is exactly the length of a byte and can be placed in a single byte. Based on this, the synchronization header area and the code block byte area are divided into separate areas in the bearer frame. As shown in FIG21 , the synchronization header area stores separated synchronization header bits, and the code block byte area stores separated data byte bits.

[0075] As shown in FIG. 22 , an embodiment of the present application illustrates step S201 , which includes but is not limited to steps S301 to S302 .

[0076] Step S301: Group multiple target bit code blocks to obtain multiple target bit code block groups.

[0077] Step S302: Separate the synchronization headers and data bytes of the multiple target bit code blocks in each target bit code block group.

[0078] In application, four 66-bit code blocks can be grouped together, and eight synchronization header bits can be separated from the four 66-bit code blocks. The eight synchronization header bits are mapped to one byte in the payload area of ​​a subframe. Four 66-bit code blocks can then be separated into 4*8 bytes, which are then mapped to the 32 bytes in the payload area of ​​the bearer frame. Thus, as shown in FIG21 , assuming the synchronization header area length is x bits and the code block byte area length is y bytes. Of course, in addition to being grouped according to the synchronization header area length x bits and the code block byte area length y bytes, all payload areas of the bearer frame can also be divided according to, but not limited to, the following methods.

[0079] Mode 1: x = 2 bits, y = 8 bytes; 1 code block constitutes a group.

[0080] Mode 2: x = 4 bits, y = 16 bytes; 2 code blocks form a group.

[0081] Mode 3: x = 6 bits, y = 24 bytes; 3 code blocks form a group.

[0082] Mode 4: x = 8 bits (i.e., one byte), y = 32 bytes; 4 code blocks form a group.

[0083] Mode 5: x = 16 bits, y = 64 bytes; 8 code blocks form a group.

[0084] Mode 6: x = 32 bits, y = 128 bytes; 16 code blocks form a group.

[0085] It should be pointed out that the above division method is applicable when the number of data bits allocated to each byte position is even. In this case, after the synchronization header bits and the data byte bits are separated, since the length of the data byte part is 64 bits, which is 8 bytes in length, a 66-bit code block can be mapped to 8 bytes, thereby further facilitating mapping and demapping.

[0086] As shown in Figure 21, the 16 columns in the first row provide 6-bit byte positions that can carry the synchronization headers of three 66-bit code blocks. The synchronization header bits of the three 66-bit code blocks are placed in these byte positions. The 16 columns in the second, third, and fourth rows provide 8-bit byte positions that can carry the synchronization headers of four 66-bit code blocks. The synchronization header bits of the four 66-bit code blocks are placed in these byte positions.

[0087] In one embodiment, multiple synchronization headers may be aggregated according to different target bit block groups to obtain multiple synchronization header sets, and multiple data bytes may also be aggregated according to different target bit block groups to obtain multiple data byte sets.

[0088] By grouping the 66-bit code block stream of Ethernet messages, the synchronization header within each group is first separated and then aggregated for transmission, while the data bytes within each group are first separated and then aggregated for transmission. Within the transport frame, the synchronization header area and the code block byte area are divided separately. The size of the synchronization header area is the same as the size of the aggregated synchronization header bits after grouping, and the size of the code block byte area is the same as the size of the aggregated data bytes after grouping. The synchronization header area stores the separated synchronization header bits, while the code block byte area stores the separated data bytes. This further facilitates the mapping and demapping of the 66-bit code blocks, achieving low cost.

[0089] In addition, as shown in Figure 23, an embodiment of the present application also discloses a communication device, including: at least one processor 210; at least one memory 220, for storing at least one program; when the at least one program is executed by at least one processor 210, a message sending method as in any of the previous embodiments is implemented.

[0090] In addition, an embodiment of the present application further discloses a computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are used to execute the message sending method in any of the previous embodiments.

[0091] The system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0092] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

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

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

Claims

1. A message sending method, comprising: Acquire a data-encoded Ethernet message, wherein the Ethernet message includes a plurality of target bit code blocks; Mapping the multiple target bit code blocks to a bearer frame, wherein the bearer frame includes a first payload area and an OMFI field, and the OMFI field is configured with a second payload area, so that the number of bits of the first payload area and the second payload area is an integer multiple of the number of bits of the target bit code block; The bearer frame is mapped to an OTN frame, and the OTN frame is sent.

2. The method according to claim 1, wherein: The second payload area includes a plurality of data bits, and 30 data bits in the second payload area are used to carry partial bits of the target bit code block.

3. The method according to claim 2, wherein: The target bit code block includes a synchronization header, and the synchronization headers of multiple target bit code blocks are carried in the 30 data bits.

4. The method according to claim 2, wherein: The second payload area includes a plurality of byte positions, and the 30 data bits are distributed among the plurality of byte positions.

5. The method according to claim 4, wherein: The data bits allocated in each of the byte positions are even numbers.

6. The method according to claim 1, wherein: The OMFI field includes data bits located in the 16th column and the 1920th column of the bearer frame, and the data bits of at least one of the 16th column and the 1920th column are configured as the second payload area.

7. The method according to claim 1, wherein: The target bit code block includes a synchronization header and data bytes, the carrying frame includes a synchronization header area and a code block byte area, the synchronization header is carried in the synchronization header area, and the data bytes are carried in the code block byte area.

8. The method according to claim 1, wherein: The target bit code block includes a synchronization header and data bytes, and the bearer frame includes a synchronization header area and a code block byte area; Mapping the multiple target bit code blocks to a bearer frame includes: separating the synchronization headers and the data bytes of the plurality of target bit code blocks; Aggregating a plurality of the synchronization headers to obtain a synchronization header set, and aggregating a plurality of the data bytes to obtain a data byte set; The synchronization header set is mapped to the synchronization header area, and the data byte set is mapped to the code block byte area.

9. The method according to claim 8, wherein: The step of separating the synchronization headers and the data bytes of the plurality of target bit code blocks comprises: Grouping the multiple target bit code blocks to obtain multiple target bit code block groups; The synchronization headers and the data bytes of the plurality of target bit code blocks in each of the target bit code block groups are separated.

10. The method according to claim 9, wherein: The step of aggregating the plurality of synchronization headers to obtain a synchronization header set includes: The plurality of synchronization headers are aggregated according to different target bit code block groups to obtain a plurality of synchronization header sets.

11. The method according to claim 9, wherein: Mapping the data byte set to the code block byte area includes: Aggregate the plurality of data bytes according to different target bit code block groups to obtain a plurality of data byte sets. combine.

12. A communication device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the message sending method according to any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the message sending method according to any one of claims 1 to 11.

Images