Message sending method, communication device and storage medium

Abstract

The embodiment of the invention provides a message sending method, communication equipment and a storage medium. The message sending method comprises the steps that an Ethernet message subjected to data coding is acquired, and the Ethernet message comprises a plurality of target bit code blocks; mapping the plurality of target bit code blocks to a bearer frame, the bearer frame comprising a first payload region and an OMFI field, the OMFI field being configured with a second payload region, such that the number of bits of the first payload region and the number of bits of the second payload region are integer multiples of the number of bits of the target bit code blocks; and mapping the bearing frame to the OTN frame, and sending the OTN frame, so that code block mapping and de-mapping become simple, and the implementation cost is low.

Description

Technical Field

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

[0002] Communication network is the highway of information age. In the past, communication content was mainly voice service. Communication network using SDH (Synchronous Digital Hierarchy) and OTN (Optical Transport Network) technology can well meet the transmission of voice service. In related technologies, OTN network carries customer service through defined ODU (Optical Data Unit) 0, ODU1, ODU2, ODU3, ODU4 and other containers. The speed of carrying customer service is 1.25G, 2.5G, 10G, 40G, etc. The minimum speed is 1.25G. Customer service with speed lower than 1.25G belongs to low-speed customer service. However, when Ethernet message in low-speed customer service is carried and transmitted in OTN network, 11 bearer frames are needed to carry an integer number of 66-bit code blocks of Ethernet message. 11 bearer frames will lead to many types of 66-bit code block boundary positions, which will bring complexity to code block mapping and demapping, and the cost is relatively high. Summary of the invention

[0003] 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 cost.

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

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

[0006] 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;

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

[0008] 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 the processor implements the message sending method as described in the first aspect when executing the computer program.

[0009] 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.

[0010] 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 includes 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, in this way, the container position of this part of the second payload area is added to the bearer frame, so that the number of bits of the entire payload area of ​​a bearer frame is just an integer multiple of the number of bits of the target bit code block, so that only one bearer frame is needed to carry an integer number of target bit code blocks, which not only facilitates the carrying and sending of Ethernet messages, but also facilitates the mapping and demapping of code blocks. Therefore, the embodiment of the present application can make code block mapping and demapping simple and low-cost. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] Figure 2 This is a schematic diagram of the structure of the OTN frame switching time slot;

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

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

[0015] Figure 5 This is a schematic diagram of the 66 encoding process of Ethernet messages;

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

[0017] Figure 7 It is the OMFI field location map;

[0018] Figure 8This is a schematic diagram of the OMFI field indicating the 66-bit mapping process;

[0019] Fig. 9 is a flow chart of a message sending method provided by an embodiment of the present application;

[0020] Fig.10 This is a schematic diagram of the fgOTN frame container structure;

[0021] Fig.11 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

[0022] Fig.12 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

[0023] Fig.13 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

[0024] Fig.14 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

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

[0026] Fig.16 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

[0027] Fig.17 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

[0028] Fig.18 This is a schematic diagram of byte position distribution of 30 data bits in the second payload area provided by an embodiment of the present application;

[0029] Fig.19 This is an embodiment of the present application. Fig. 9 Flow chart of step S102 in FIG.

[0030] Fig. 20 It is a schematic diagram of the separation of the synchronization header and data bytes of a 66-bit code block;

[0031] Fig.21 It is a schematic diagram of the mapping of the synchronization header and data bytes of a 66-bit code block respectively;

[0032] Fig. 22 This is an embodiment of the present application. Fig.19 Flow chart of step S201 in FIG.

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

[0034] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0035] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification and claims and the following drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

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

[0037] 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 first given below.

[0038] The communication network is the highway of the information age. In the past, the communication content was mainly voice services. The communication network using SDH and OTN technologies has well met the transmission of voice services. The OTN network carries customer services through defined containers such as ODU0, ODU1, ODU2, ODU3, and ODU4. The speeds of carrying customer services are 1.25G, 2.5G, 10G, 40G, etc., and the minimum speed is 1.25G. It is necessary to provide a method for efficiently and conveniently transmitting customer services less than 1.25G in traditional OTN frames. The low-speed customer service described in this application refers to customer services with a speed lower than 1.25G.

[0039] OTN communication equipment is based on the G.709 protocol standard. The process of OTN delivering customer services is as follows: customer services are first mapped to OPU (optical payload unit), OPU is then mapped to ODU (optical data unit), and ODU is finally mapped to OTN frame for transmission. Figure 1As shown, the frame consists of 4*3824 bytes (4 rows and 3824 columns). In the figure, OPU OH (OPU overhead) is the OPU overhead field, located in the 16th and 17th columns 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 positioning mark. Customer services are loaded and delivered in the OPU, that is, the payload area of ​​the OTN frame. The OTN frame payload area is located in the 18th-3824th columns of the frame. The 17th to 3284th byte area in the figure is the bearer area of ​​the OTN frame (or called the OTN frame payload area). Time slots are divided in the bearer area of ​​the OTN frame. Each time slot is 16 bytes. Each row in the bearer area of ​​the OTN frame has 3824-16=3808 bytes, which can be divided into 238 time slots. The 4-row bearer area customer divides 952 time slots, as shown in the figure. Figure 2 As shown. The size of each time slot is 16 bytes, and the corresponding bearer service speed of each time slot is 10M (actually slightly larger than 10M, after deducting various overheads, the customer service speed is guaranteed to reach 10M). For a customer service with a speed of 10M, the customer service is first mapped to a subframe or basic frame, and then a time slot position is selected in the OTN frame for carrying. Each time slot carries 16 bytes of subframe or basic frame content each time. After many times of carrying, the carrying and transmission of all bytes of the basic frame are completed. In specific applications, customer services are not carried directly on the time slot. Customer services are first mapped to the bearer frame, and then the bearer frame is mapped to the time slot for carrying. The international standard has established a specific structure of the bearer frame, named fgOTN frame, also called basic frame. Its frame structure is as follows Figure 3 As shown in the figure, the basic frame consists of 4 rows and 3824 columns, with 3824 bytes in each row. Columns 1-16 and 1905-1920 are overheads, and the remaining columns are used to carry customer services. When carrying customer services, customer services are mapped into fgOTN frames, and fgOTN frames are then carried in OTN frames and sent as customer service content. 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 then the customer service is extracted and restored from the fgOTN frame.

[0040] Before mapping Ethernet services to fgOTN frames, Ethernet packets need to be 64 / 66 encoded, such as Figure 5As shown in the figure, for every 8 bytes (64 bits in total) of the customer content, 2 bits are added to expand it into a 66-bit information block, and the added 2 bits are located in front of the 66-bit block (these two bit values ​​are fixed to "01" or "11", "01" indicates that the information code block is a data code block, and "11" indicates that the information code block is a control code block), and the synchronization header bit is located at the front of the code block. The 64-bit content of 8 bytes is converted into a 66-bit code block before being mapped to the fgOTN frame for carrying. At the receiving end, the 66-bit information code block is extracted and identified from the fgOTN, and the original 8-byte (64-bit data) customer service is restored from the 66-bit information code block, and the customer message is reassembled. Figure 6 It is the 64 / 66 encoding rule of Ethernet 802.3 protocol. Each code block consists of 66 bits. The first 2 bits are the synchronization header of the code block. The synchronization header bit is "01" which means it is a D code block (data code block). The following 8 bytes (64 bits) are 8 bytes of data content. The synchronization header bit is "10" which means it is a control code block. The first byte that follows indicates the type of control block. The following 7 bytes are the content of the control block. The 7 bytes are determined by the type of control block. Figure 6 As shown. Both S code blocks and T code blocks belong to control code blocks. The first byte content in the S code block is 0x78, indicating that the control code block is an S code block. In addition to indicating that it is an end block, the T code block can also carry customer byte content (located in the last 7 bytes of the code 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 content is 0x87) does not carry customer information, the T1 code block (the first byte content is 0x99) carries 1 byte of customer information, the T2 code block (the first byte content is 0xAA) carries 2 bytes of customer information, and so on. The T7 code block (the first byte content is 0xFF) carries 7 bytes of customer information.

[0041] Each Ethernet message becomes a 66-bit code block stream after 64 / 66 encoding. The message consists of an S code block, several D code blocks and a T code block. Since each code block is 66 bits long, and the payload area in fgOTN is composed of many bytes, each fgOTN payload area has 121344 bits, and 121344 is not a multiple of 66, resulting in the boundary of the 66 code block in the fgOTN frame cannot be fixed. In order to indicate the boundary of the 66-bit code block, such as Figure 7 As shown, the OMFI field is set in the 16th and 1920th columns of the fgOTN frame overhead field to determine the boundary of the 66-bit code block in the fgOTN frame. The specific principle is: Figure 8As shown, the payload area of ​​the first fgOTN frame can carry 1838 66-bit code blocks and 36 bits in a code block. The remaining 66-36=30 bits of the code block continue to be carried in the second fgOTN (a code block is divided and carried in two frames), and then continue to carry the subsequent 66-bit code blocks. In the second fgOTN, after carrying 1838 66-bit code blocks, the remaining space can only carry 6 bits in a code block. The third fgOTN carries in a similar way, first carrying the previous code block 66-6=60 bits, then continuing to carry 66-bit code blocks, and finally carrying bits less than a code block. The 4th, 5th, ... 10th frames are the same, until the 11th fgOTN completely carries an integer number of 66-bit code blocks. An integer number of 66-bit code blocks can be carried in 11 fgOTN frames, and the OMFI field is used to determine the order of the 11 fgOTN frames, where the OMFI field content in the first fgOTN frame is all 0, the OMFI field content in the second fgOTN frame is all 1, the OMFI field content in the third fgOTN frame is all 2, and so on, the OMFI field content in the tenth fgOTN frame is all 9, and the OMFI field content in the eleventh fgOTN frame is all 10. The order of the fgOTN frames can be determined by the OMFI field content, and then the boundary position of the 66-bit code block in the frame can be determined.

[0042] The method of determining the order of fgOTN frames through the OMFI field content and then determining the 66-bit code block boundary is a feasible implementation method, but the implementation method is complex and requires determining the OMFI field content and then determining the 66-bit code block boundary position. In the 11 fgOTN frames, there are many types of code block boundary positions, and code block mapping and demapping bring complexity and high cost.

[0043] Based on this, the present application provides a message sending method, a communication device and a storage medium. The message sending method of one embodiment includes: obtaining a data-encoded Ethernet message, the Ethernet message includes 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 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, in this way, the container position of this part of the second payload area is added to the bearer frame, so that the number of bits of the entire payload area of ​​a bearer frame is just an integer multiple of the number of bits of the target bit code block, so that only one bearer frame is needed to carry an integer number of target bit code blocks, which not only facilitates the carrying and sending of Ethernet messages, but also facilitates the mapping and demapping of code blocks. Therefore, the embodiment of the present application can make code block mapping and demapping simple and low-cost.

[0044] The embodiments of the present application are further described below in conjunction with the accompanying drawings.

[0045] like Fig. 9 As shown, Fig. 9 It 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.

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

[0047] Step S102: mapping 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 in the target bit code block;

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

[0049] In this step, the Ethernet message after data encoding is obtained, and 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 the 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 bearer frame is then mapped to the OTN frame and the OTN frame is sent. In this way, the container position of this part of the second payload area is added to the bearer frame, so that the number of bits of the entire payload area of ​​a bearer frame is just an integer multiple of the number of bits of the target bit code block, so that only one bearer frame is needed to carry an integer number of target bit code blocks, which is not only convenient for Ethernet message carrying and sending, but also convenient for code block mapping and demapping, so that code block mapping and demapping can be simplified and implemented at a low cost.

[0050] In one embodiment, the bearer frame is an fgOTN frame having 4 rows and 3824 columns, each column of each row has 1 byte, and the number of bits of each byte is 8. Figure 7 As shown in FIG. 1 , columns 17 to 1904 and columns 1921 to 3824 of the fgOTN frame are the first payload area. Columns 16 and 1920 of the fgOTN frame are the OMFI field, as shown in FIG. Fig.10 As shown, the number of bits in each row of bytes in the OMFI field of the 16th column is 8, and the number of bits in each row of bytes in the OMFI field of the 16th column is also 8. The number of bits in the first payload area in the fgOTN frame is 60416+60928=121344. Remove the original indication function of the OMFI field, change the 16th column and the 1920th column to the payload area function, and 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.

[0051] In one embodiment, the second payload area includes a plurality of data bits, and 30 data bits in the second payload area are used to carry part of the bits of the target bit code block. Taking the target bit code block as a 66-bit code block as an example, 30 bits of the newly added 64 bits can be used to carry customer services, that is, these 30 bits are used to carry part of the bits of the 66-bit code block, and the other 34 bits are used as fixed insertion bits and do not carry customer services. Then, the payload area that effectively carries customer services in the fgOTN has a total of 121344+30=121374 bits, which can just carry 1839 code blocks of 66 bits in length. In this case, the boundary position of the 66-bit code block is fixed in each fgOTN frame, which is convenient for the mapping process of the code block, thereby simplifying the circuit design.

[0052] In one embodiment, the OMFI field includes data bits located in the 16th column and the 1920th column of the bearer frame. Specifically, 8 bytes may be added to the 16th column and the 1920th column of each row in each fgOTN frame, for a total of 64 bits. For carrying a 66-bit code block, only 30 bits need to be provided for carrying the 66-bit code block, and the other 36 bits may be reserved, so that the total payload area of ​​the fgOTN frame becomes 121344+30=121374 bits for carrying a 66-bit code block.

[0053] It should be noted that the specific positions of the 30 data bits in the second payload area can be distributed in a variety of 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 30 data bits are provided from the 16th column; only the data bits of the 1920th column can be configured as the second payload area, that is, only 30 data bits are provided from the 1920th column; or a total of 30 data bits can be provided from the 16th column and the 1920th column.

[0054] In one embodiment, the second payload area may include a plurality of byte positions, and the 30 data bits in the second payload area may be allocated to the plurality of 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, and 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, and the remaining 14 data bits may be allocated to two byte positions that can provide 7 data bits. It can be seen that the data bits allocated to each byte position may be an odd number or an even number. It should be pointed out that, when the data bits allocated to each byte position are an even number, since the synchronization header of the 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 a 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.

[0055] In one embodiment, if Fig.11As shown, the byte positions of the 30 data bits in the second payload area can be: the byte position of the 16th column of the first row provides 6 bits (6 bits of the 8 bits of the byte position are used as the payload area function, and the other 2 bits are not used), and the 1920th column of the first row provides 8 bits (all 8 bits of the byte position are used as the payload area function). The 16th column and the 1920th column of the second row both provide 8 bits (all 8 bits of the byte position are used as the payload area function). The 16th column and the 1920th column of the third to fourth rows are reserved and not used.

[0056] In one embodiment, if Fig.12 As shown, the 30 data bits in the second payload area may be distributed in byte positions as follows: the 16th column of the first row provides 6 bits (8 bits of the 8 bits in the byte position are used as the payload area function, and the other bit is not used). The 16th columns of the second to fourth rows all provide 8 bits (all 8 bits of the byte position are used as the payload area function). The 1920th columns of the first to fourth rows are all reserved and not used.

[0057] In one embodiment, if Fig.13 As shown, the 30 data bits in the second payload area may be distributed in byte positions as follows: the 16th column of the first row and the 1920th byte position provide 7 bits (7 of the 8 bits in the byte position are used as the payload area function, and the other 1 bit is not used). The 16th column of the second row and the 1920th column both provide 8 bits (all 8 bits in the byte position are used as the payload area function). The 16th column of the third and fourth rows, and the 1920th column of the third and fourth rows are reserved and not used.

[0058] In one embodiment, if Fig.14 As shown, the 30 data bits in the second payload area may be distributed in byte positions as follows: the byte position of the 16th column of the first and second rows provides 7 bits (7 of the 8 bits in the byte position are used as the payload area function, and the other 1 bit is not used). The 16th column of the third and fourth rows both provide 8 bits (all 8 bits in the byte position are used as the payload area function). The 1920th column of the first to fourth rows is reserved and not used.

[0059] In one embodiment, if Fig.15 As shown, the 30 data bits in the second payload area may be distributed in byte positions as follows: the 16th column byte position of the first and third rows provides 7 bits (7 of the 8 bits in the byte position are used as the payload area function, and the other 1 bit is not used). The 16th column of the second and fourth rows both provide 8 bits (all 8 bits in the byte position are used as the payload area function). The 1920th column of the first to fourth rows is reserved and not used.

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

[0061] In one embodiment, if Fig.17 As shown, the byte positions of the 30 data bits in the second payload area can be distributed as follows: 3 bits are provided at the byte position of the 16th column of the first and second rows (3 bits of the 8 bits at this byte position are used as the payload area function, and the other 5 bits are not used). 4 bits are provided at the byte position of the 1920th column of the first and second rows (4 bits of the 8 bits at this byte position are used as the payload area function, and the other 4 bits are not used). 4 bits are provided at the byte position of the 16th column and the 1920th column of the third and fourth rows (4 bits of the 8 bits at this byte position are used as the payload area function, and the other 4 bits are not used).

[0062] In one embodiment, if Fig.18 As shown, the byte positions of the 30 data bits in the second payload area can be: 3 bits are provided at the byte position of the 16th column of the first and third rows (3 bits of the 8 bits at this byte position are used as the payload area function, and the other 5 bits are not used). 4 bits are provided at the byte position of the 1920th column of the first and third rows (4 bits of the 8 bits at this byte position are used as the payload area function, and the other 4 bits are not used). 4 bits are provided at the byte position of the 16th column and the 1920th column of the second and fourth rows (4 bits of the 8 bits at this byte position are used as the payload area function, and the other 4 bits are not used).

[0063] It should be noted that the above are only a few implementation examples 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 implementation examples, and the present application does not make any specific limitations on this.

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

[0065] When the payload area size of each bearer frame that effectively carries 66-bit code blocks is an integer multiple of 66, each bearer frame can carry exactly 1839 code blocks of 66 bits in length, which is convenient for mapping and demapping. However, since each code block is 66 bits long, and the payload area in the bearer frame is composed 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, and the starting position of the 66-bit code block is different in each byte, which still brings some inconvenience to mapping and demapping.

[0066] 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, and 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.

[0067] like Fig.19 As shown, an embodiment of the present application further illustrates step S102, which includes but is not limited to steps S201 to S203.

[0068] Step S201: Separating synchronization headers and data bytes of multiple target bit code blocks;

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

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

[0071] In this step, if Fig. 20 As shown, taking the target bit code block as a 66-bit code block as an example, the synchronization header part and the data byte part of the 66-bit code block can be separated, and then multiple synchronization headers can be aggregated to obtain a synchronization header set, and multiple data bytes can be aggregated to obtain a data byte set, and then the synchronization header set can be mapped to the synchronization header area, and the data byte set can be mapped to the code block byte area. For 66-bit code blocks, each 66-bit code block has 2 synchronization header bits, and 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 part is 64 bits, which is 8 bytes in length, a 66-bit code block can be mapped to 8 bytes, which further facilitates mapping and demapping. The 2-bit synchronization headers of 4 66-bit code blocks are 8 bits in total, which is exactly one byte length and can be placed in one byte. Based on this, the synchronization header area and the code block byte area are divided separately in the bearer frame, as shown in Fig.21As shown, the synchronization header area stores separated synchronization header bits, and the code block byte area stores separated data byte bits.

[0072] like Fig. 22 As shown, an embodiment of the present application further illustrates step S201, where step S201 includes but is not limited to steps S301 to S302.

[0073] Step S301: grouping a plurality of target bit code blocks to obtain a plurality of target bit code block groups;

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

[0075] In application, 4 66-bit code blocks can be used as a group, 8 synchronization header bits can be separated from 4 66-bit code blocks, and the 8 synchronization header bits can be mapped to one byte in the payload area of ​​a subframe. 4*8 bytes can be separated from 4 66-bit code blocks and mapped to 32 bytes in the payload area of ​​the bearer frame. Fig.21 As shown, it is assumed that the synchronization header area length is x bits and the code block byte area length is y bytes. Of course, in addition to being divided 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 the following methods, including but not limited to:

[0076] Mode 1: x = 2 bits, y = 8 bytes; 1 code block as a group;

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

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

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

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

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

[0082] It should be pointed out that the above division method is applicable when the data bits allocated to each byte position are an even number. 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, a 66-bit code block can be mapped to 8 bytes, thereby further facilitating mapping and demapping.

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

[0084] 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.

[0085] By grouping the 66-bit code block stream of the Ethernet message, the synchronization header in each group is separated first and then concentrated for carrying, and the data bytes in each group are separated first and then concentrated for carrying. The synchronization header area and the code block byte area are divided separately in the carrying frame, and the size of the synchronization header area is the same as the size of the synchronization header bits concentrated after grouping, and the size of the code block byte area is the same as the size of the data bytes concentrated after grouping. The synchronization header area stores the separated synchronization header bits, and the code block byte area stores the separated data bytes, which further facilitates the mapping and demapping processing of the 66-bit code blocks and achieves low cost.

[0086] In addition, if Fig.23 As shown, 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 the at least one processor 210, a message sending method as in any of the previous embodiments is implemented.

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

[0088] 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.

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

[0090] In 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 physical components 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 of ordinary skill 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 include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that 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.

[0091] The terms "component", "module", "system", etc. used in this specification are used to represent 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 may reside in a process or an execution thread, and a component may be located on a computer or distributed between two or more computers. In addition, these components may be executed from various computer-readable media having various data structures stored thereon. Components may 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 between a local system, a distributed system, or a network, such as the Internet interacting with other systems through 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, characterized in that 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, characterized in that 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, characterized in that: 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, characterized in that The data bits allocated in each of the byte positions are even numbers.

6. The method according to claim 1, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that Mapping the data byte set to the code block byte area includes: The plurality of data bytes are aggregated according to different target bit code block groups to obtain a plurality of data byte sets.

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