CN108809901B

CN108809901B - Method, equipment and system for carrying service

Info

Publication number: CN108809901B
Application number: CN201710301888.6A
Authority: CN
Inventors: 苏伟; 操时宜
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-05-02
Filing date: 2017-05-02
Publication date: 2021-05-04
Anticipated expiration: 2037-05-02
Also published as: CN108809901A; CN113316037B; CN113316037A

Abstract

The application provides a method, equipment and a system for bearing service, wherein the method comprises the following steps: the method comprises the steps that sending end equipment obtains a flexible Ethernet Flexe client signal; converting the Flexe client signal into a Flexe service frame, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal; mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame; and sending the Flexe overhead frame out through the physical channel. In the application, the Flexe client signal is converted into the Flexe service frame, and the Flexe service frame carries the overhead information of the Flexe client signal, so that end-to-end network management and monitoring of the Flexe client signal can be realized.

Description

Method, equipment and system for carrying service

Technical Field

The present application relates to the field of communications, and in particular, to a method, a device, and a system for service bearer.

Background

Currently, flexible Ethernet Implementation agent 1.0 (FlexE IA 1.0) interface technology is standardized in Optical Interconnection Forum (OIF). The FlexE can be applied to interconnection of data center equipment and the like, and transmits a plurality of paths of FlexE client services with different rates, such as FlexE client services of 10G, n × 25G, 40G and the like, by binding n 100G physical layer devices (PHYs).

For long-distance transmission, FlexE may encapsulate FlexE client traffic into FlexE signals, and then carry and transmit the FlexE signals over an Optical Transport Network (OTN). As shown in fig. 1, the FlexE signal from FlexE 101 to FlexE 103, or the FlexE signal from FlexE 103 to FlexE 101 may pass through OTN 102, and long distance transmission is achieved by using OTN as a carrier network. In the prior art, the feedthrough of the FlexE signal through the OTN can be achieved in three ways: (1) FlexE unaware (FlexE unit), i.e. considering n × 100G FlexE signals as n independent 100GE (gigabit Ethernet) signals, and complete the carrying and transmission through n ODU4(optical data unit-4 ). (2) And (4) Flexe sensing (Flexe aware), namely analyzing the n × 100G Flexe signal, deleting the invalid time slot of the Flexe signal, and completing bearing and transmission through 1 path or multiple paths of ODUflex. (3) The FlexE terminates (FlexE terminate), that is, deep parsing is performed on n × 100G FlexE signals, multiple paths of FlexE client services with different rates are parsed, and then, the multiple paths of FlexE client services with different rates complete bearing and transmission through the ODUflex respectively.

With the evolution of FlexE technology, FlexE is likely to be a transport network technology like OTN. Therefore, to implement the transport function of FlexE, it is necessary to solve the problem of end-to-end network management and monitoring in FlexE.

Disclosure of Invention

In view of this, the present application provides a method, a device, and a system for service bearer, which can solve the problem that end-to-end network management and monitoring cannot be performed in FlexE.

In a first aspect, the present application provides a method for service transmission, including: the method comprises the steps that sending end equipment obtains a flexible Ethernet Flexe client signal; converting the Flexe client signal into a Flexe service frame, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal; mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame; and sending the Flexe overhead frame out through the physical channel.

In the application, the Flexe client signal is converted into the Flexe service frame, and the Flexe service frame carries the overhead information of the Flexe client signal, so that end-to-end network management and monitoring of the Flexe client signal can be realized.

In a possible implementation manner, the converting the FlexE client signal into a FlexE service frame includes: periodically inserting the at least one first overhead code block into the Flexe traffic frame.

In this application, the first overhead code blocks may be periodically carried in the FlexE service frame, for example, one or more first overhead code blocks occur in every other preset number of code blocks in the FlexE service frame.

In a possible implementation manner, the converting the FlexE client signal into a FlexE service frame includes: 1/(2) of the frame length of a Flexe client signalⁿ) And converting the Flexe client signal into the Flexe service frame by taking the unit as a unit, wherein n is greater than or equal to 0.

In the method and the device, the Flexe client signals with the preset length are converted into the Flexe service frames, so that the complexity of signal processing is reduced, and the transmission efficiency is improved.

In a possible implementation manner, before mapping the FlexE service frame into one or more time slots of a physical channel, the method further includes: rate adaptation is performed on the FlexE client signal.

In a possible implementation manner, the converting the FlexE client signal into a FlexE service frame includes: encoding overhead information of the Flexe client signal to generate the at least one first overhead code block.

In a possible implementation manner, the at least one first overhead code block is located in a header of the FlexE service frame, and/or the at least one first overhead code block is located between any two data code blocks of the FlexE service frame.

In a second aspect, the present application provides a method for service reception, including: receiving end equipment receives a flexible Ethernet Flexe overhead frame from a physical channel; identifying the overhead information of the Flexe overhead frame, and demapping one or more time slots of the physical channel according to the overhead information of the Flexe overhead frame to obtain a Flexe service frame, wherein the overhead information of the Flexe overhead frame is carried by a second overhead code block of the Flexe overhead frame; and converting the Flexe service frame into a Flexe client signal, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal.

In the application, the Flexe service frame is converted into a Flexe client signal, and the Flexe service frame carries overhead information of a Flexe client, so that end-to-end network management and monitoring of the Flexe client signal can be realized.

In a possible implementation manner, the converting the FlexE service frame into a FlexE client signal includes: periodically identifying the at least one first overhead code block from the Flexe traffic frame.

In the present application, the first overhead code blocks may be periodically identified from the FlexE traffic frame, for example, one or more first overhead code blocks are identified in every preset number of code blocks in the FlexE traffic frame.

In a possible implementation manner, the converting the FlexE service frame into a FlexE client signal includes: 1/(2) of length of one Flexe service frameⁿ) And converting the Flexe service frame into a Flexe client signal by taking the Flexe service frame as a unit, wherein n is greater than or equal to 0.

In the application, the Flexe service frame with the preset length is converted into the Flexe client signal, so that the complexity of signal processing is reduced, and the transmission efficiency is improved.

In a possible implementation manner, the converting the FlexE service frame into a FlexE client signal includes: deleting the synchronous head bit of the FlexE service frame, decoding the FlexE service frame, and filling a reserved field.

In a third aspect, the present application provides a transmitting device, comprising: the receiving module is used for acquiring a flexible Ethernet Flexe client signal; a processing module, configured to convert the FlexE client signal into a FlexE service frame, where the FlexE service frame includes at least one first overhead code block and at least one data code block, the at least one first overhead code block is used to carry overhead information of the FlexE client signal, and the at least one data code block is used to carry payload information of the FlexE client signal; mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame; and the sending module is used for sending the Flexe overhead frame out through the physical channel.

In a possible implementation manner, the processing module is configured to: periodically inserting the at least one first overhead code block into the Flexe traffic frame.

In a possible implementation manner, the processing module is configured to: 1/(2) of the frame length of a Flexe client signalⁿ) And converting the Flexe client signal into the Flexe service frame by taking the unit as a unit, wherein n is greater than or equal to 0.

In a possible implementation manner, the processing module is further configured to: rate adaptation is performed on the FlexE client signal.

In a fourth aspect, the present application provides a receiving apparatus, comprising: a receiving module, configured to receive a flexible ethernet FlexE overhead frame from a physical channel; the processing module is used for identifying the overhead information of the Flexe overhead frame, and obtaining a Flexe service frame by demapping one or more time slots of the physical channel according to the overhead information of the Flexe overhead frame, wherein the overhead information of the Flexe overhead frame is carried by a second overhead code block of the Flexe overhead frame; and converting the Flexe service frame into a Flexe client signal, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal.

In a possible implementation manner, the processing module is configured to: periodically identifying the at least one first overhead code block from the Flexe traffic frame.

In a possible implementation manner, the processing module is configured to: 1/(2) of length of one Flexe service frameⁿ) And converting the Flexe service frame into a Flexe client signal by taking the Flexe service frame as a unit, wherein n is greater than or equal to 0.

In a possible implementation manner, the processing module is configured to: deleting the synchronous head bit of the FlexE service frame, decoding the FlexE service frame, and filling a reserved field.

In a fourth aspect, an embodiment of the present invention provides a network system, including a sending device in any one of possible implementation manners of the third aspect or the third aspect, and a receiving device in any one of possible implementation manners of the fourth aspect or the fourth aspect.

Yet another aspect of the present application provides a computer-readable storage medium having stored therein instructions, which when executed on a computer, cause the computer to perform the method of the above-described aspects.

Yet another aspect of the present application provides a computer program product containing instructions which, when run on a computer, cause the computer to perform the method of the above-described aspects.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the background art and the embodiments will be briefly described below.

FIG. 1 is a schematic diagram of a network architecture of a Flexe signal pass-through OTN in the prior art;

fig. 2 is a schematic diagram of a network architecture of an OTN signal feedthrough FlexE according to an embodiment of the present invention;

fig. 3 is a schematic diagram of a frame structure of an OTN frame in the prior art;

fig. 4 is a schematic diagram of converting an OTN frame into a FlexE service frame according to an embodiment of the present invention;

fig. 5a is a schematic diagram of a code block format of a FlexE service frame according to an embodiment of the present invention;

fig. 5b is a schematic diagram of a code block format of a FlexE service frame according to an embodiment of the present invention;

fig. 6a is a schematic format diagram of a FlexE service frame according to an embodiment of the present invention;

fig. 6b is a schematic diagram of another FlexE service frame format according to an embodiment of the present invention;

fig. 7 is a schematic diagram of a format of an overhead code block according to an embodiment of the present invention;

fig. 8 is a schematic format diagram of a FlexE service frame according to an embodiment of the present invention;

fig. 9 is a schematic processing diagram of service transmission according to an embodiment of the present invention;

fig. 10 is a schematic processing diagram of timeslot distribution according to an embodiment of the present invention;

fig. 11 is a schematic diagram of a process for inserting FlexE overhead code blocks according to an embodiment of the present invention;

fig. 12 is a schematic processing diagram of service transmission according to an embodiment of the present invention;

fig. 13 is a schematic processing diagram of service transmission according to an embodiment of the present invention;

fig. 14 is a schematic processing diagram of another service transmission provided in the embodiment of the present invention;

fig. 15 is a schematic processing diagram of service reception according to an embodiment of the present invention;

FIG. 16 is a schematic diagram of a network architecture according to an embodiment of the present invention;

fig. 17 is an exemplary flowchart of a method for service transmission according to an embodiment of the present invention;

fig. 18 is an exemplary flowchart of a method for receiving a service according to an embodiment of the present invention;

fig. 19 is a schematic structural diagram of a transmitting device according to an embodiment of the present invention;

fig. 20 is a schematic structural diagram of a receiving device according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments.

Fig. 2 is a schematic diagram of a network architecture of an OTN signal feedthrough FlexE according to an embodiment of the present invention. As shown in fig. 2, the OTN 201 may encapsulate the client service of the client device 204 into an OTN signal, carry and transmit the OTN signal through the FlexE 202, and the OTN 203 receives the OTN signal, restores the client service from the OTN signal, and sends the client service to the client device 205. Or, the OTN 203 may encapsulate the client service of the client device 205 into an OTN signal, carry and transmit the OTN signal through the FlexE 202, and the OTN 201 receives the OTN signal, restores the client service from the OTN signal, and sends the client service to the client device 204. The

client devices

204, 205 may be data centers, routers, servers, computers, and the like. When the OTN signal is carried and transmitted through the FlexE 202, the frame format of the OTN signal is converted into a frame format suitable for a FlexE service frame transmitted in the FlexE. The frame format of the Flexe service frame provided by the embodiment of the invention has a good corresponding relation with the frame format of the OTN frame, thereby simplifying the process of signal processing and improving the efficiency of signal processing. In addition, overhead information of the OTN frame is reserved in the Flexe service frame, and end-to-end network management and monitoring can be realized.

In the embodiment of the present invention, the OTN signal and the OTN frame may refer to the same object, such as OTUk (optical transport unit-k), OTUCn (optical transport unit-Cn), and the like; the optical data unit-k, the ODUflex (flexible optical data unit-flex), the ODUCn (optical data unit-Cn), and the like; and may also include OPUk (optical payload unit-k), OPUflex (optical payload unit-flex), OPUCn (optical payload unit-Cn), etc. Where k may be 0, 1, 2, 2e, 3, 4, etc., and Cn represents an integer multiple of 100G.

Fig. 3 is a schematic diagram of a frame structure of an OTN frame in the prior art. As shown in fig. 3, a frame structure of an ODUk or ODUflex is taken as an example for explanation. An OTN frame may comprise 4 rows x3824 columns of bytes. Wherein, the 1 st column to the 16 th column are overhead information of the OTN frame, and the 17 th column to the 3824 th column are payload information of the OTN frame. The overhead information of the OTN frame may include a frame alignment overhead, an OTU (optical transport unit) overhead, an OPU (optical payload unit) overhead, and an ODU (optical data unit) overhead, etc. The frame alignment overhead may include a FAS (frame alignment signal) and/or an MFAS (multi frame alignment signal). The ODU overhead may include: PM (path monitoring), TCM (distance connection monitoring), EXP (experimental), GCC (general communication channel), APS (automatic protection switching), PCC (protection communication channel), and the like. The PM may further include TTI (trace identifier), BIP8(bit interleaved parity-level 8), BEI (backward error indication), BDI (backward defect indication), STAT (status), and the like.

The first transformation mode is as follows:

fig. 4 is a schematic diagram of converting an OTN frame into a FlexE service frame according to an embodiment of the present invention. As shown in fig. 4, a FlexE service frame converted from an OTN frame may include a start code blockS, 1910 data code blocks D and 1 frame-end code block T. The S, D, T codeblocks may be 66B codeblocks. The 66B code block, which may also be referred to as a 64B/66B code block, includes a 2-bit sync header and 64-bit data. In one example, 1/(2) of the length of an OTN frame can be usedⁿ) In units, every 8 bytes, starting from the starting byte of the OTN frame, translates into a 66B code block. 1/(2) of an OTN frameⁿ) Can be converted into a compound including 1912/(2)ⁿ) FlexE traffic frames of 66B code blocks. Wherein, the FlexE service frame may include a start code block S, 1912/(2)ⁿ) 2 data code blocks D and 1 end-of-frame code block T. Wherein n is greater than or equal to 0. When n is 0, the conversion is carried out by taking the length of one OTN frame as a unit, and the converted Flexe service frame comprises 1912 code blocks. When n is 1, the conversion is performed by taking 1/2 OTN frame lengths as units, and the converted FlexE service frame contains 956 code blocks. When n is 2, the conversion is performed by taking 1/4 OTN frame lengths as units, and the converted FlexE service frame includes 478 code blocks. And so on. In practical applications, n may be smaller than 0, such as n-1, -2, etc. One FlexE service frame may contain 3824, 7648, etc. code blocks.

In this example, an OTN frame is taken as an ODUk or ODUflex for example. Of course, the embodiment of the present invention is also applicable to OPUk, OPUflex, and the like, and the number of 66B code blocks included in a FlexE service frame converted from OPUk or OPUflex may be different from that of a FlexE service frame converted from ODUk or ODUflex. For example, one OPUk or OPUflex may be converted into a FlexE traffic frame comprising 1905 66B code blocks.

Taking n-0 as an example, that is, 1 OTN frame is converted into a FlexE service frame (e.g., the FlexE service frame shown in fig. 4) including 1912 66B code blocks. Fig. 5a is a schematic diagram of a code block format of a FlexE service frame according to an embodiment of the present invention. As shown in fig. 5a, a starting code block of the FlexE service frame, that is, an S code block, may carry header information of an i +1 th frame ODUk or ODUflex. An end of frame code block, i.e., a T code block, of the FlexE service frame may carry end of frame information of the i-th frame ODUk or ODUflex. The S code block may also use the idle field D1 to carry the last byte in the i-th frame ODUk or ODUflex frame tail information. Fig. 5b is a schematic diagram of a code block format of a FlexE service frame according to an embodiment of the present invention. As shown in fig. 5b, the data code block, i.e. the D code block, of the FlexE service frame may carry intermediate bytes of the ODUk or ODUflex, i.e. bytes except for the header information and the trailer information.

(1) The S code block may be generated by the frame header information of the OTN frame, i.e., the first 8 overhead bytes in the first row. The S code block may include a 2-bit sync header "10", an 8-bit code block type field "0 x 78", and the remaining 7 bytes for carrying the first 8 overhead bytes of the first row of the OTN frame. Since 7 bytes are not enough to fully carry 8 overhead bytes, 8 overhead bytes of the OTN frame can be compressed. For example, the 1 st to 6 th bytes of the first row of the OTN frame carry fixed pattern information, "0 xF6F 6282828", and the repeated bytes of the first row of the OTN frame may be discarded, for example, any two "F6F 6" bytes or any two "2828" bytes. Thus, the header information of the OTN frame, i.e. the first 8 overhead bytes of the first line, is compressed into 6 bytes. In another example, the 5 th byte and the 6 th byte in the first row of the OTN frame may be placed in a 66B code block converted from the reserved byte in the overhead region of the OTN frame, and the 5 th byte and the 6 th byte corresponding to the first row of the OTN frame occupy the reserved field of the reserved byte in the 66B code block in the overhead region of the OTN frame. For example, the 5 th and 6 th bytes in the first row of the OTN frame may occupy the reserved field in the 66B code block converted from the 1 st and 2 nd reserved bytes of the overhead area in the second row or the 9 th to 14 th reserved bytes of the overhead area in the fourth row of the OTN frame.

(2) The T code block can be generated by converting the frame tail information of the OTN frame, namely the last 8 bytes of the fourth line. The T-code block may include a 2-bit sync header "10", an 8-bit code block type field "0 xff", and the remaining 7 bytes for carrying the last 8 bytes of the fourth row of the OTN frame. Since the overhead bytes carried by the S code block are compressed, there are 1 idle field D1 in the S code block that can carry the end-of-frame information of the OTN frame. In another example, one byte of the frame end of the OTN frame may be placed in the reserved field of the 66B code block converted from the reserved byte of the overhead area of the OTN frame.

As shown in fig. 5a, the frame header information of the i +1 th frame ODUk or ODUflex, "0 xF6F 6282828+ MFAS + D1" is compressed into 6 bytes, and then placed in the D2 to D7 fields of the S code block. The D1 field of the S code block may be used to carry one byte D8 in the frame tail information of the i-th frame ODUk or ODUflex. The i-th frame ODUk or ODUflex has 7 bytes of frame tail information, "D1D 2D3D4D5D6D 7", which is placed in the D1 to D7 fields of the T code block.

(3) D code blocks, which may be generated by converting the middle bytes of the OTN frame, i.e. the bytes except the first 8 overhead bytes of the first row and the last 8 bytes of the fourth row. As shown in fig. 5b, the D code block may include a 2-bit sync header "01", and the remaining 8 bytes are used to carry any 8 middle bytes of the OTN frame. For example, consecutive 8 middle bytes may be placed in the D1-D8 fields of one D code block.

And (2) a second transformation mode:

fig. 6a is a schematic format diagram of a FlexE service frame according to an embodiment of the present invention. Fig. 6b is a schematic format diagram of another FlexE service frame according to the embodiment of the present invention. In one example, the overhead code block may be placed in the header position of a FlexE service frame. As shown in fig. 6a, one FlexE frame may include x 66B overhead code blocks OH and consecutive y 66B data code blocks D. The x 66B overhead code blocks are arranged at the frame header positions of the Flexe service frames. In another example, the overhead code blocks of the FlexE service frame may be inserted into the FlexE service frame at a certain period. As shown in fig. 6B, one FlexE traffic frame may include z groups of p 66B overhead code blocks. And taking p 66B overhead code blocks as a unit, and interpolating at z positions of the Flexe service frame according to a certain period. Alternatively, p 66B overhead code blocks are inserted in front of every q 66B data code blocks. As shown in fig. 6a or 6b, the overhead code block may carry one or more types of overhead information for end-to-end management monitoring, such as any one or more of TTI, BIP8, BEI, BDI, STAT, etc. In addition, the overhead code block can also be used for carrying frame header positioning overhead (FAS/MFAS) and the like.

Fig. 7 is a schematic diagram of a format of an overhead code block according to an embodiment of the present invention. As shown in fig. 7, the overhead code block may be a 66B code block including a 2-bit sync header "10" and an 8-bit code block type field "0 x 4B". In the existing standard, "0 x4 b" is a code block type that has been used, and thus a 4-bit "0 xa" code block type field can also be set for identification. Alternatively, the code block type field may also be set to a code block type that is not used in the existing standard, for example, "0 x 4C". If the code block type field in the overhead code block occupies 8 bits, the remaining 56 bits may be used to carry overhead information of the OTN frame. But each row of the OTN frame contains 16 overhead bytes, if the overhead bytes of each row of the OTN frame are placed completely in 2 overhead codeblocks, each overhead codeblock should contain 64 bits to carry the overhead bytes of the OTN frame. Therefore, part of the overhead bytes in the OTN frame, such as TCM, APS, PCC, etc., may be discarded, set to the reserved field RES in the overhead code block, or filled with all 0 s in the fields of the overhead code block.

Fig. 8 is a schematic format diagram of a FlexE service frame according to an embodiment of the present invention. Similar to the 1 st conversion method, the length of the OTN frame can be 1/(2) } of the length of the OTN frameⁿ) In units, every 8 bytes, starting from the starting byte of the OTN frame, translates into a 66B code block. Similarly, an OTN frame is an ODUk or ODUflex, and n is 0. As shown in fig. 8, in units of one ODUk or ODUflex frame, the first 16 bytes of each row of the ODUk or ODUflex are converted into two 66B overhead code blocks, and the remaining 3808 bytes are converted into 476 66B data code blocks. 2 66B overhead code blocks are inserted per 476 66B data code blocks, so that a total of 8 66B overhead code blocks (overhead code block OH1, overhead code block OH2 … … overhead code block OH7, overhead code block OH8) are inserted into 4 groups of 476 66B data code blocks. An ODUk or ODUflex is converted into a FlexE traffic frame containing 8 66B overhead code blocks plus 4x476 66B data code blocks. The overhead code block OH1 carries 1 st to 8 th overhead bytes in the 1 st row of the ODUk or ODUflex, and the overhead code block OH2 may carry 9 th to 16 th overhead bytes in the 1 st row of the ODUk or ODUflex. The overhead code block OH3 may carry overhead bytes 1 to 8 of the 2 nd row of the ODUk or ODUflex, and the overhead code block OH4 may carry overhead bytes 9 to 16 of the 2 nd row of the ODUk or ODUflex. The overhead code block OH5 may carry 1 st to 8 th overhead bytes in the 3 rd row of the ODUk or ODUflex, and the overhead code block OH6 may carry 9 th to 16 th overhead bytes in the 3 rd row of the ODUk or ODUflex. The overhead code block OH7 may carry 1 st to 8 th overhead bytes of the 4 th row of the ODUk or ODUflex, and the overhead code block OH8 may carry the 4 th row of the ODUk or ODUflexAnd 9 th to 16 th overhead bytes.

(1) The overhead code block may be used to carry overhead information (overhead bytes) of the OTN frame. As shown in fig. 8, the overhead code block OH1 may carry frame header positioning overhead FAS and MFAS, and the overhead code block OH6 may carry path management monitoring overhead PM (including TTI, BIP8, BDI, BEI, etc.). Reserved fields may be set in overhead code blocks OH2, OH3, OH4, OH5, OH7, OH 8. Of course, when other overhead bytes of the OTN frame need to be added, it may be set in the reserved field of the overhead code block. In the embodiment of the invention, OAM (operation, administration and maintenance) characteristics of the OTN frame are reserved in the Flexe service frame, and end-to-end network management and monitoring can be realized by using overhead information of the OTN frame.

(2) D code block, which may be used to carry payload information (payload bytes) of the OTN frame. The format of the D code block may be as shown with reference to fig. 5 b. The 17 th to 3824 th bytes of each row of the OTN frame may be converted into 476D code blocks, D may be a 66B code block including a 2-bit sync header "01", and the remaining 8 bytes may be used to place any 8 bytes of the 17 th to 3824 th bytes of each row of the OTN frame. For example, the consecutive 8 bytes in the payload region of the OTN frame may be placed in the D1-D8 fields of one D code block.

In the embodiment of the present invention, if the FlexE service frame is converted into the OTN frame, the 2-bit synchronization header of each 66B code block in the FlexE service frame may be deleted, and the code block type field of the overhead code block may be converted into the reserved byte of the OTN frame. One FlexE service frame can be converted into exactly one OTN frame, and original overhead information of the OTN frame can be recovered. The Flexe service frame and the OTN frame in the embodiment of the invention have good correspondence on the frame structure, and when the Flexe service frame is converted into the OTN frame, the Flexe service frame does not need to be mapped into the payload of the OTN frame and the overhead of the OTN frame is regenerated, thereby reducing the complexity of signal processing and improving the transmission efficiency.

The following describes the processing procedure of FlexE service transmission:

fig. 9 is a schematic processing diagram of service transmission according to an embodiment of the present invention. As shown in fig. 9, the FlexE interface forms a FlexE group (also referred to as a FlexE member group) by binding N PHY (also referred to as PHY members or FlexE members) lanes, and transmits a plurality of FlexE services (also referred to as FlexE clients, FlexE client signals, FlexE client services, etc.) of different rates through the FlexE group bound by the N PHY lanes. At least three-way FlexE traffic is shown in fig. 9, for example, the FlexE traffic may include OTN signals (or referred to as OTN traffic), packet traffic, ethernet traffic, and the like. The bandwidth of each PHY channel may be 100G, 200G, 400G, etc. For example, in the existing FlexE standard, a PHY channel of 100G is used. In the shim layer (caledar or main time hierarchy) of the FlexE, the FlexE group may be divided into 20xN slots of 5G granularity (caledar slots). Each PHY channel is divided into 20 5G slots.

And step 900, acquiring at least one Flexe service. Such as ODUk or ODUflex, FlexE service # a and FlexE service # z, etc. In this embodiment, an ODUk or an ODUflex is taken as an example for explanation, and a FlexE service # a, a FlexE service # z, and the like are described in the embodiment shown in fig. 12. The ODUk or ODUflex may be carried and transmitted as a client signal of FlexE through FlexE.

In step 901, the obtained FlexE service is converted into a FlexE service frame. For example, for the ODUk or the ODUflex, any one of the conversion manners in the above embodiments may be adopted, or any two or more conversion manners are combined to convert the ODUk or the ODUflex into a FlexE service frame.

Step 902, performing rate adaptation on the FlexE service frame.

The purpose of rate adaptation is to make the FlexE service frame occupy an integer number of slots in the FlexE shim layer in step 903.

For example, if the ODUk or ODUflex is converted into the FlexE service frame in the first conversion mode or the second conversion mode, an IDLE code block (IDLE) or a preset special code block may be added to the FlexE service frame for rate adaptation.

If the ODUk or ODUflex is first converted into the FlexE service frame a of the first conversion mode, and then the FlexE service frame a is converted into the FlexE service frame B of the second conversion mode, an IDLE code block (IDLE) or a preset special code block may be added to the FlexE service frame a for rate adaptation, or an IDLE code block (IDLE) or a preset special code block may be added to the FlexE service frame B for rate adaptation. For example, an IDLE code block (IDLE) or a preset special code block may be added between the T code block of the previous FlexE service frame a and the S code block of the next FlexE service frame a. Alternatively, an IDLE code block (IDLE) or a preset special code block is added between two FlexE service frames B. The conversion of the FlexE service frame a into the FlexE service frame B can be realized by inserting an overhead code block for carrying overhead information of the OTN frame based on the FlexE service frame a. The 66B code blocks of the FlexE traffic frame a may include any one or more of S code blocks, T code blocks, D code blocks, and idle code blocks. The frame format of the FlexE service frame B can be seen in the embodiment shown in fig. 8. The 66B code block of the FlexE traffic frame a may be considered as the D code block of the FlexE traffic frame B. For example, in the FlexE traffic frame a, 2 66B overhead code blocks are inserted every 476 66B code blocks, generating the FlexE traffic frame B. Alternatively, in the FlexE service frame a, 2 overhead code blocks of 66B are inserted every 478 code blocks of 66B, so that one FlexE service frame a is converted into exactly one FlexE service frame B.

Step 903, generating a FlexE group signal: and allocating one or more time slots for the Flexe service frame according to the bandwidth of the Flexe service frame, and mapping the Flexe service frame subjected to rate adaptation to the allocated one or more time slots. The one or more slots herein may be any of 20xN slots divided in the FlexE shim layer. For example, the bandwidth of the ODU0 is 1.25G, and a 5G timeslot may be allocated to a FlexE service frame generated by the ODU 0. The bandwidth of the ODU2 is 10G, and 25G timeslots may be allocated to a FlexE service frame generated by the ODU 2. If multiple time slots are allocated, they may be located in the same PHY channel or in different PHY channels.

Fig. 10 is a schematic processing diagram of timeslot distribution according to an embodiment of the present invention. As shown in fig. 10 (taking 4 PHY channels as an example for explanation), the Calendar is divided into 20 × 4 time slots, and each PHY channel (or sub-Calendar) is divided into 20 time slots (identified as time slot 0-time slot 19). In fig. 10, 2 time slots are allocated to a FlexE service frame generated by the ODU2, where 1 time slot is located in the PHY channel 1 and another time slot is located in the PHY channel 2. Alternatively, 2 timeslots of a FlexE service frame generated by the ODU2 may all be located in the PHY channel 1.

Step 904, generating a PHY channel signal: and distributing the Flexe group signal carrying the Flexe service frame to one or more PHY channels, and adding overhead information of a Flexe overhead frame. The overhead information of the FlexE overhead frame may include a FlexE group number, a PHY lane number, slot occupancy indication information, and the like. The PHY channel signal may be transmitted in a FlexE overhead frame format, and one PHY channel signal may correspond to one FlexE overhead frame. As shown in fig. 10, 4 PHY channel signals are generated, where the ODU2 is carried in PHY channel signal 1 and PHY channel signal 2.

Fig. 11 is a schematic diagram of a process for inserting FlexE overhead code blocks according to an embodiment of the present invention. The overhead information of the FlexE overhead frame may include several FlexE overhead code blocks inserted at a certain period in the PHY channel signal. As shown in fig. 11, the FlexE overhead frame may be formed by any PHY channel signal. In one cycle, 1 FlexE overhead code block may be inserted before every 20 × 1023 data code blocks. One FlexE overhead frame may include 8 consecutive periods, i.e., 8 FlexE overhead code blocks, plus 8x (20x1023) data code blocks. Wherein several periodically occurring data code blocks can be transmitted through 1 slot. As shown in fig. 11, the 1 st slot transmits a data code block "1" that periodically occurs every 20 code blocks, the 2 nd slot transmits a data code block "2" that periodically occurs every 20 code blocks, …, and the 20 th slot transmits a data code block "20" that periodically occurs every 20 code blocks. The FlexE service frame may be carried in any code block of 20 × 1023 data code blocks and transmitted through a time slot corresponding to the carried data code block. For example, a FlexE service frame generated by the ODU0 is at the position of the data code block "2" and is transmitted through the 2 nd slot.

Step 905, scramble the generated PHY channel signal.

Step 906, an Alignment Mark (AM) is inserted into the PHY channel signal for alignment of different virtual channels in the same PHY. The AM may be identified as the start of frame of the PHY channel signal.

Step 907, performing FEC encoding processing on the PHY channel signal, and sending out the processed PHY channel signal.

Some of the above steps may not be executed, or the execution order is not limited to the above example. For example, step 902, step 907, etc. may not be performed. Step 902 may also be performed before step 901.

Fig. 12 is a schematic processing diagram of service transmission according to an embodiment of the present invention. As shown in fig. 12, the difference from fig. 9 is that, in the embodiment of the present invention, a FlexE service other than an ODUk or an ODUflex may also be converted into a FlexE service frame in any one of the embodiments.

Step 1200, acquiring at least one path of Flexe service. Such as FlexE service # a, FlexE service # b, FlexE service # z, etc.

Step 1201, performing rate adaptation on the acquired FlexE service.

For example, rate adaptation is performed for FlexE service # a. The FlexE service # a may be a packet service or an ethernet service (e.g., GE, 10GE), etc. Packet traffic may consist of a series of ethernet frames and frame gaps. The length of each ethernet frame may not be fixed and includes 1 66B start code block (S), several 66B data code blocks (D) and 1 frame end code block (T). A frame gap may include several IDLE code blocks (IDLE). IDLE code blocks (IDLE) may be added and/or deleted for rate adaptation of FlexE traffic # a.

Step 1202, the FlexE service is converted into a FlexE service frame.

For example, the FlexE service # a is converted into a FlexE service frame. For example, 2 66B overhead code blocks may be periodically inserted every 476 66B code blocks in packet traffic. The consecutive 4 groups (476 66B code blocks +2 66B overhead code blocks) constitute one FlexE traffic frame. The frame format of the FlexE service frame can be seen with reference to fig. 8. The 66B code blocks of the packet service may include any one or more of S code blocks, D code blocks, T code blocks, and IDLE code blocks. The inserted 66B overhead code blocks may be preset by the transmitting end or generated from packet traffic. The 66B overhead codeblock may carry one or more types of overhead information for end-to-end management monitoring, e.g., any one or more of TTI, BIP8, BEI, BDI, STAT, etc.

Optionally, step 1201 may be performed before step 1202, or may be performed after step 1202. Alternatively, step 1201 may not be performed.

Step 1203-. The frame structure of the Flexe service provided by the embodiment of the invention is suitable for any Flexe service. Due to the good corresponding relation between the Flexe service frame and the OTN frame, when the Flexe signal needs to pass through the OTN, the processing complexity of converting the Flexe service frame into the OTN frame is reduced, and the conversion efficiency is improved. End-to-end network management and monitoring can be achieved by using the overhead of the Flexe service frame.

Fig. 13 is a schematic processing diagram of service transmission according to an embodiment of the present invention. As shown in fig. 13, the FlexE traffic may be an ODUKm in an OTN frame. For example, the ODUKm may be an ODUCn having a rate of an integer multiple of 100G, or the rate of the ODUKm may also be an integer multiple of 200G, or the like.

Step 1300, the ODUKm may be distributed into m channels of ODUK (ODUK #1, ODUK #2, as an ODUK # m), which is equivalent to changing the FlexE service from 1 channel to m channels. The frame structure of the ODUKm may be formed by interleaving m ODUK frames, and the frame format of each ODUK frame may refer to the OTN frame structure shown in fig. 3.

Step 1301, converting each path of ODUK into any one of the FlexE service frames according to the embodiments of the present invention, to obtain m paths of FlexE service frames. For example, each path of ODUK is converted into a FlexE service frame by using any one of the foregoing conversion methods. In another example, the ODUKm may not be distributed into m channels of ODUK, and the ODUKm is regarded as a time channel of FlexE service and converted into a FlexE service frame. For example, one ODUKm may be converted into one FlexE service frame, 1/m ODUKm may be converted into one FlexE service frame, and 1/(2) may be further convertedⁿxm) ODUKm are converted into one FlexE service frame.

Steps 1302-.

Fig. 14 is a schematic processing diagram of another service transmission provided in the embodiment of the present invention. As shown in fig. 14, the difference from fig. 13 is that the slot allocation of the FlexE shim layer in step 1403 is omitted. And 1401 and 1404, after m FlexE service frames are obtained, distributing the m FlexE service frames to m PHY channels, where each FlexE service frame corresponds to one PHY channel. And adding Flexe overhead code blocks to the Flexe service frames in each PHY channel at a certain period to form m Flexe overhead frames, namely m PHY channel signals. The other steps are similar to fig. 13.

Fig. 15 is a schematic processing diagram of service reception according to an embodiment of the present invention. The processing procedure of service reception and the processing procedure of service transmission are roughly reversed, and a service reception procedure corresponding to fig. 9 will be described as an example.

Step 1500, receiving one or more PHY channel signals.

For example, in fig. 15, N PHY channel signals are received, e.g., PHY channel signal #1, PHY channel signals #2, …, PHY channel signal # N, etc.

Step 1501, identifying an AM in the PHY channel signal, aligning a plurality of virtual channels in the PHY according to the AM in the PHY channel signal, and deleting the AM to obtain an aligned PHY channel signal.

Step 1502, FEC decoding is performed on the recovered PHY channel signal.

In step 1503, the PHY channel signal is descrambled.

The

steps

1501 and 1503 and 905 and 907 are inverse processes to each other, and if the sender does not execute one or more of the

steps

905 and 907, the receiver may not perform corresponding inverse processing. For example, if the transmitting end does not perform FEC encoding, the receiving end may not perform FEC decoding.

Step 1504, extracting the overhead information of the FlexE overhead frame of each PHY channel signal, and restoring the N PHY channel signals to FlexE group signals.

In step 1505, a FlexE service frame is demapped from one or more slots of a FlexE group signal.

For example, the slot occupation indication information in the overhead code block of the FlexE overhead frame is analyzed, and the FlexE service frame is obtained by demapping from one or more slots of the FlexE group signal.

Step 1506, rate adaptation is performed on the FlexE service frame.

For example, an IDLE code block (IDLE) or a pre-defined special code block is added and/or deleted at an arbitrary position of the FlexE service frame to implement rate adaptation.

Optionally, if the FlexE service frame obtained by demapping in step 1505 is a FlexE service frame (FlexE service frame B) according to the second conversion method, the FlexE service frame B may be first converted into a FlexE service frame (FlexE service frame a) according to the first conversion method, and then rate adaptation is performed based on the FlexE service frame a. The rate adaptation can be realized by adding or deleting IDLE code blocks between the T code block of the last FlexE service frame and the S code block of the next FlexE service frame.

Step 1507, identify the overhead code block of the FlexE service frame, and convert the FlexE service frame into an ODUk or ODUflex. For example, a FlexE traffic frame has 2 overhead code blocks per 476 data code blocks. Overhead code blocks of a FlexE service frame may be periodically detected, and when frame positioning overhead FAS and/or MFAS is obtained, a frame header of an ODUk or ODUflex may be determined. After a FlexE service frame can be acquired, the FlexE service frame is converted into an ODUk or ODUflex. Or after one or more code blocks of the FlexE service frame are acquired, the acquired code blocks may be converted into partial bytes of the ODUk or ODUflex.

Some of the above steps may not be executed, or the execution order is not limited to the above example. For example, step 1502, step 1506, etc. may not be performed. Step 1506 may also be performed after step 1507.

The embodiment of the invention can also be applied to the scene that the Flexe signal passes through the OTN. Fig. 16 is a schematic diagram of a network architecture according to an embodiment of the present invention. As shown in fig. 16, the source device and the sink device are respectively located in the FlexE network 1 and the FlexE network 2, and signals transmitted between the two FlexE networks are carried and transmitted through the OTN. The OTN may use any OTN frame (e.g., ODUflex) to carry the FlexE signal. The FlexE signal may be a FlexE service frame or a FlexE overhead frame carrying a FlexE service frame. The edge device B of the FlexE network 1 is connected to the edge device C of the OTN, so that the FlexE network 1 is connected into the OTN. The edge device E of the FlexE network 2 is connected to the edge device D of the OTN, so that the FlexE network 2 is connected into the OTN. Edge device B or edge device E may access the OTN through the FlexE membership group.

The source end device may convert the FlexE service into a FlexE service frame, for example, the FlexE service may include an OTN signal, a packet service, an ethernet service, and the like. The FlexE service frame may carry a 66B overhead code block, and when the edge device C of the OTN converts the FlexE service frame into the ODUflex, the 66B overhead code block of the FlexE service frame may be converted into an overhead byte. The edge device D of the OTN restores the ODUflex into a FlexE service frame, and the sink device receives the FlexE service frame, and can restore the FlexE service frame into a FlexE service. Because the FlexE service frame can carry overhead information, end-to-end network management and monitoring can be realized through the FlexE service frame.

Fig. 17 is an exemplary flowchart of a method for service transmission according to an embodiment of the present invention. As shown in fig. 17, the method may be performed by a transmitting end device. The method may comprise the steps of:

s1701: a flexible ethernet FlexE client signal is acquired.

The FlexE client signal may be obtained from the client device or may be generated by the sending end device. The FlexE client signals may include, for example, OTN signals (alternatively referred to as OTN traffic), packet traffic, ethernet traffic, and the like.

S1702: and converting the Flexe client signal into a Flexe service frame, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal.

Optionally, the at least one first overhead code block is periodically inserted into the FlexE traffic frame. 1/(2) of the frame length of a Flexe client signalⁿ) And converting the Flexe client signal into the Flexe service frame by taking the unit as a unit, wherein n is greater than or equal to 0. For example, when n is 0, one FlexE client signal frame may be converted into one FlexE service frame. Optionally, the overhead information of the FlexE client signal is encoded to generate the at least one first overhead codeAnd (5) blocking. Optionally, the at least one first overhead code block is located in a header of the FlexE service frame, and/or the at least one first overhead code block is located between any two data code blocks of the FlexE service frame. For example, when the FlexE client signal is an OTN frame, the overhead information of the FlexE client signal may include any one or more of a frame header positioning overhead and a path management monitoring overhead, and may be used for end-to-end network management and monitoring.

S1703: and mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame.

Optionally, before a FlexE service frame is mapped to one or more time slots of a physical channel, rate adaptation may be performed on the FlexE client signal. The rate adapted FlexE client signal can be mapped to exactly an integer number of slots of the physical channel.

S1704: and sending the Flexe overhead frame out through the physical channel.

Fig. 18 is an exemplary flowchart of a method for receiving a service according to an embodiment of the present invention. As shown in fig. 18, the method may be performed by a receiving end device. The method may comprise the steps of:

s1801: a flexible ethernet FlexE overhead frame is received from a physical channel.

The FlexE overhead frame may be directly received from the sending end device, or may be received after being sent by the sending end device and passing through one or more intermediate devices.

S1802: and identifying the overhead information of the Flexe overhead frame, and demapping one or more time slots of the physical channel according to the overhead information of the Flexe overhead frame to obtain a Flexe service frame, wherein the overhead information of the Flexe overhead frame is carried by a second overhead code block of the Flexe overhead frame.

The overhead information of the FlexE frame may include slot occupancy indication information for indicating from which slot/slots the FlexE service frame is to be fetched.

S1803: and converting the Flexe service frame into a Flexe client signal, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal.

Optionally, the at least one first overhead code block is periodically identified from the FlexE traffic frame. 1/(2) of length of one Flexe service frameⁿ) And converting the Flexe service frame into a Flexe client signal by taking the Flexe service frame as a unit, wherein n is greater than or equal to 0. In the process of converting the FlexE service frame into the FlexE client signal, the sync header bit of the FlexE service frame may be deleted, the FlexE service frame may be decoded, and the reserved field may be filled. The at least one first overhead code block is located in a header of the FlexE service frame, and/or the at least one first overhead code block is located between any two data code blocks of the FlexE service frame.

Fig. 19 is a schematic structural diagram of a transmitting apparatus 1900 according to an embodiment of the present invention. The sending device 1900 may be an optical transport device, an ethernet device, a flexible ethernet device, a router, a switch, etc. As shown in fig. 19, the transmitting device 1900 may include a receiving module 1901, a processing module 1902, and a transmitting module 1903.

A receiving module 1901, configured to obtain a flexible ethernet FlexE client signal.

A processing module 1902, configured to convert the FlexE client signal into a FlexE service frame, where the FlexE service frame includes at least one first overhead code block and at least one data code block, where the at least one first overhead code block is used to carry overhead information of the FlexE client signal, and the at least one data code block is used to carry payload information of the FlexE client signal; and mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame.

A sending module 1903, configured to send out the FlexE overhead frame through the physical channel.

The transmitting device 1900 may perform the method steps in any of the embodiments shown in fig. 9, 12, 13, 14, 17.

Fig. 20 is a schematic structural diagram of a receiving device 2000 according to an embodiment of the present invention. The receiving apparatus 2000 and the transmitting apparatus 1900 shown in fig. 19 may be located in the same apparatus or may be located in different apparatuses. The receiving device 2000 may be an optical transmitting device, an ethernet device, a flexible ethernet device, a router, a switch, etc. As shown in fig. 20, the receiving apparatus 2000 may include a receiving module 2001 and a processing module 2002.

A receiving module 2001, configured to receive a flexible ethernet FlexE overhead frame from the physical channel.

And a processing module 2002, configured to identify the overhead information of the FlexE overhead frame, and obtain a FlexE service frame by demapping from one or more time slots of the physical channel according to the overhead information of the FlexE overhead frame, where the overhead information of the FlexE overhead frame is carried by a second overhead code block of the FlexE overhead frame. And converting the Flexe service frame into a Flexe client signal, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal.

The receiving device 2000 may perform the method steps as shown in any one of the embodiments shown in fig. 15 and fig. 18.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

Claims

1. A method for service delivery, the method comprising:

acquiring a flexible Ethernet Flexe client signal;

converting the Flexe client signal into a Flexe service frame, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal;

mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame;

and sending the Flexe overhead frame out through the physical channel.

2. The method of claim 1, wherein said translating said FlexE client signals into FlexE service frames comprises:

periodically inserting the at least one first overhead code block into the Flexe traffic frame.

3. The method according to claim 1 or 2, wherein said converting said FlexE client signals into FlexE traffic frames comprises:

1/(2) of the frame length of a Flexe client signalⁿ) And converting the Flexe client signal into the Flexe service frame by taking the unit as a unit, wherein n is greater than or equal to 0.

4. The method of claim 1, wherein prior to mapping the Flexe traffic frame into one or more slots of a physical channel, the method further comprises:

rate adaptation is performed on the FlexE client signal.

5. The method according to claim 1 or 2, wherein said converting said FlexE client signals into FlexE traffic frames comprises:

encoding overhead information of the Flexe client signal to generate the at least one first overhead code block.

6. The method according to claim 1 or 2, wherein the at least one first overhead code block is located in a header of the FlexE traffic frame and/or wherein the at least one first overhead code block is between any two data code blocks of a FlexE traffic frame.

7. A method of service reception, the method comprising:

receiving a flexible Ethernet Flexe overhead frame from a physical channel;

identifying the overhead information of the Flexe overhead frame, and demapping one or more time slots of the physical channel according to the overhead information of the Flexe overhead frame to obtain a Flexe service frame, wherein the overhead information of the Flexe overhead frame is carried by a second overhead code block of the Flexe overhead frame;

and converting the Flexe service frame into a Flexe client signal, wherein the Flexe service frame comprises at least one first overhead code block and at least one data code block, the at least one first overhead code block is used for carrying overhead information of the Flexe client signal, and the at least one data code block is used for carrying payload information of the Flexe client signal.

8. The method of claim 7, wherein said converting said Flexe traffic frames to Flexe client signals comprises:

periodically identifying the at least one first overhead code block from the Flexe traffic frame.

9. The method according to claim 7 or 8, wherein said converting said FlexE service frames into FlexE client signals comprises:

1/(2) of length of one Flexe service frameⁿ) And converting the Flexe service frame into a Flexe client signal by taking the Flexe service frame as a unit, wherein n is greater than or equal to 0.

10. The method according to claim 7 or 8, wherein said converting said FlexE service frames into FlexE client signals comprises:

deleting the synchronous head bit of the FlexE service frame, decoding the FlexE service frame, and filling a reserved field.

11. The method according to claim 7 or 8, wherein the at least one first overhead code block is located in a header of the Flexe traffic frame and/or wherein the at least one first overhead code block is between any two data code blocks of a Flexe traffic frame.

12. A transmitting device, characterized in that the device comprises:

the receiving module is used for acquiring a flexible Ethernet Flexe client signal;

a processing module, configured to convert the FlexE client signal into a FlexE service frame, where the FlexE service frame includes at least one first overhead code block and at least one data code block, the at least one first overhead code block is used to carry overhead information of the FlexE client signal, and the at least one data code block is used to carry payload information of the FlexE client signal; mapping the Flexe service frame to one or more time slots of a physical channel to generate a Flexe overhead frame, wherein the Flexe overhead frame comprises a second overhead code block which is used for carrying overhead information of the Flexe overhead frame;

and the sending module is used for sending the Flexe overhead frame out through the physical channel.

13. The device of claim 12, wherein the processing module is to:

14. The device of claim 12 or 13, wherein the processing module is to:

15. The device of claim 12, wherein the processing module is further to:

rate adaptation is performed on the FlexE client signal.

16. The apparatus according to claim 12 or 13, wherein said converting said FlexE client signals into FlexE traffic frames comprises:

17. The apparatus according to claim 12 or 13, wherein the at least one first overhead code block is located in a header of the FlexE traffic frame, and/or wherein the at least one first overhead code block is between any two data code blocks of a FlexE traffic frame.

18. A receiving device, characterized in that the device comprises:

a receiving module, configured to receive a flexible ethernet FlexE overhead frame from a physical channel;

the processing module is used for identifying the overhead information of the Flexe overhead frame, and obtaining a Flexe service frame by demapping one or more time slots of the physical channel according to the overhead information of the Flexe overhead frame, wherein the overhead information of the Flexe overhead frame is carried by a second overhead code block of the Flexe overhead frame;

19. The device of claim 18, wherein the processing module is to:

20. The apparatus of claim 18 or 19, wherein the processing module is to:

21. The apparatus of claim 18 or 19, wherein the processing module is to:

22. The apparatus according to claim 18 or 19, wherein the at least one first overhead code block is located in a header of the FlexE traffic frame, and/or wherein the at least one first overhead code block is between any two data code blocks of a FlexE traffic frame.

23. A network system, characterized in that the system comprises a transmitting device according to any of claims 12-17 and a receiving device according to any of claims 18-22.

24. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any of claims 1-6.

25. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 7-11.