Bearer frame, bearer method, electronic device, storage medium, and program product

Abstract

Provided in the present application are a bearer frame, a bearer method, an electronic device, a storage medium, and a program product. The bearer frame is composed of an S code block, a D code block, and a T code block, and includes an overhead area and a bearer area, wherein the overhead area is used for carrying overhead information; and the bearer area is used for carrying client content of a first service. Idle code blocks are inserted between a plurality of bearer frames and are then mapped to sub-slots of a service layer for transmission, wherein one bearer frame is used for carrying one or more first services.

Description

Bearer frames, bearing methods, electronic devices, storage media and program products

[0001] Cross-referencing

[0002] This application claims priority to Chinese Patent Application No. 202510114301.5, filed on January 24, 2025, entitled "Bearer Frame, Bearer Method, Electronic Device, Storage Medium and Program Product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a carrier frame, a carrier method, an electronic device, a storage medium, and a program product. Background Technology

[0004] The Flexible Ethernet (FlexE) protocol standard specification defines a method for transmitting customer services at speeds of n (n is a positive integer) * 5G (in bits per second). The FlexE physical interface can efficiently carry customer services at speeds above 5G. To address the need to carry customer services at speeds below 5G, the protocol standard also specifies a fine-grained frame structure, dividing a 5G speed FlexE slot into 480 sub-slots, each with a bandwidth of 10M, capable of carrying customer services at 10M and above.

[0005] For services within the Synchronous Digital Hierarchy (SDH) standard, such as TU12, VC12, VC4, or AU4 services, the aforementioned sub-time slots can also be used for service transmission in related technologies. However, there are currently no relevant solutions. Summary of the Invention

[0006] This application provides a carrier frame, a carrier method, an electronic device, a storage medium, and a program product.

[0007] In a first aspect, a bearer frame is provided, which consists of an S-code block, a D-code block, and a T-code block, and includes an overhead area and a bearer area; wherein the overhead area is used to carry overhead information; the bearer area is used to carry the client content of a first service; after inserting idle code blocks between multiple bearer frames, they are mapped to sub-slots of the service layer for transmission, and one bearer frame is used to carry one or more of the first services.

[0008] In a second aspect, a method for carrying a service based on the bearer frame described in the first aspect is provided, applied at a transmitting end, comprising: mapping a first service to be carried to the bearer frame; mapping the bearer frame to the sub-time slot; and sending the sub-time slot to a receiving end.

[0009] Thirdly, a method for carrying a bearer frame based on the bearer frame described in the first aspect is provided, applied at a receiving end, comprising: receiving a sub-time slot transmitted by a transmitting end; parsing the sub-time slot to extract the bearer frame in the sub-time slot; and parsing the S-code block, D-code block, and T-code block in the bearer frame to extract the client content of the first service carried by the bearer frame.

[0010] Fourthly, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in the second or third aspect.

[0011] Fifthly, a computer-readable storage medium is provided, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method as described in the second or third aspect.

[0012] In a sixth aspect, a computer program product is provided, the computer program product including a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps in the method as described in the second aspect, or to perform some or all of the steps in the method as described in the third aspect. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 is a schematic diagram of how the existing FlexE protocol combines four 100G optical modules to form a 400G transmission channel.

[0015] Figure 2 is a schematic diagram of the data block transmission format for 100G services in related technologies;

[0016] Figure 3 is a schematic diagram of the code blocks included in the fine-grained frame structure in the related technology;

[0017] Figure 4 is a schematic diagram of a fine-grained frame structure developed in related technologies;

[0018] Figure 5 is a schematic diagram of another fine-grained frame structure developed in related technologies;

[0019] Figure 6 is a schematic diagram of a carrier frame according to an embodiment of this application;

[0020] Figure 7 is a schematic diagram of a carrier frame according to an embodiment of this application;

[0021] Figure 8 is a schematic diagram of the overhead area of ​​an embodiment of this application;

[0022] Figure 9 is a schematic diagram of a carrier frame according to an embodiment of this application;

[0023] Figure 10 is a schematic diagram of a specific byte being carried at a fixed position in the carrying area according to an embodiment of this application;

[0024] Figure 11 is a schematic diagram of an embodiment of this application in which a specific byte position value indicates the position of a specific byte in the bearer area;

[0025] Figure 12 is a schematic diagram of a specific byte position value indicating the position of a specific byte in the bearer area according to an embodiment of this application;

[0026] Figure 13 is a schematic diagram of a specific byte position value indicating the position of a specific byte in the bearer area according to an embodiment of this application;

[0027] Figure 14 is a schematic diagram of the TU12 service structure according to an embodiment of this application;

[0028] Figure 15 is a schematic diagram of the structure of a carrying frame in an embodiment of this application when carrying TU12 services;

[0029] Figure 16 is a schematic diagram of the structure of a bearer frame in an embodiment of this application when carrying TU12 services;

[0030] Figure 17 is a schematic diagram of an embodiment of this application in which four TU12 bearer frames are interleaved and mapped to a sub-time slot in frame-by-frame order.

[0031] Figure 18 is a schematic diagram of an embodiment of this application in which four TU12 bearer frames are interleaved and mapped to a sub-slot in units of code blocks.

[0032] Figure 19 is a schematic diagram of deinterleaving four TU12 bearer frames in a frame-by-frame manner according to an embodiment of this application;

[0033] Figure 20 is a schematic diagram of deinterleaving four TU12 bearer frames in units of code blocks according to an embodiment of this application;

[0034] Figure 21 is a schematic diagram of a bearer frame of 19 code blocks carried by V1 byte at a fixed position in the bearer area, carrying one TU12 service in an embodiment of this application.

[0035] Figure 22 is a schematic diagram of a bearer frame of 19 code block lengths carrying one TU12 service and the V1 byte at the dynamically changing position of the bearer area according to an embodiment of this application.

[0036] Figure 23 is a schematic diagram of a bearer frame of 19 code blocks carried by the V1 byte at a fixed position in the bearer area, carrying four TU12 services according to an embodiment of this application.

[0037] Figure 24 is a schematic diagram of a bearer frame of 19 code block lengths carrying four TU12 services and V1 bytes at dynamically changing positions in the bearer area according to an embodiment of this application.

[0038] Figure 25 is a schematic diagram of the alignment of the V1 byte position in a four-channel TU12 service according to an embodiment of this application;

[0039] Figure 26 is a schematic diagram of a bearer frame of 74 code blocks carried by V1 byte at a fixed position in the bearer area, according to an embodiment of this application, carrying one TU12 service.

[0040] Figure 27 is a schematic diagram of a bearer frame of 73 code blocks carried by V1 byte at a fixed position in the bearer area, according to an embodiment of this application, carrying one TU12 service.

[0041] Figure 28 is a schematic diagram of a bearer frame of 74 code blocks carried by V1 byte at the dynamically changing position of the bearer area, carrying one TU12 service in an embodiment of this application.

[0042] Figure 29 is a schematic diagram of a bearer frame of 73 code blocks carried by the V1 byte at the dynamically changing position of the bearer area, carrying one TU12 service in an embodiment of this application.

[0043] Figure 30 is a schematic diagram of a bearer frame of 74 code blocks carried by a fixed position of the V1 byte in the bearer area, carrying four TU12 services according to an embodiment of this application.

[0044] Figure 31 is a schematic diagram of a bearer frame of 73 code blocks carried by a fixed position of the V1 byte in the bearer area, carrying four TU12 services according to an embodiment of this application.

[0045] Figure 32 is a schematic diagram of a bearer frame carrying four TU12 services and 74 code blocks of V1 bytes at the dynamically changing position of the bearer area according to an embodiment of this application.

[0046] Figure 33 is a schematic diagram of a bearer frame carrying four TU12 services and 73 code blocks of V1 byte at the dynamically changing position of the bearer area according to an embodiment of this application.

[0047] Figure 34 is a schematic diagram of a bearer frame of 46 code blocks carrying four TU12 services and V1 bytes at dynamically changing positions in the bearer area according to an embodiment of this application.

[0048] Figure 35 is a schematic diagram of a bearer frame of 45 code blocks carried by the V1 byte at the dynamically changing position of the bearer area, carrying four TU12 services according to an embodiment of this application.

[0049] Figure 36 is a schematic diagram of the VC12 business structure according to an embodiment of this application;

[0050] Figure 37 is a schematic diagram of the AU4 service structure according to an embodiment of this application;

[0051] Figure 38 is a simplified schematic diagram of the AU4 service structure according to an embodiment of this application;

[0052] Figure 39 is a schematic diagram of a bearer frame of 122 code blocks carried by the H1 byte at the dynamically changing position of the bearer area, carrying one AU4 service in an embodiment of this application.

[0053] Figure 40 is a schematic diagram of a bearer frame of 121 code blocks carried by the H1 byte at the dynamically changing position of the bearer area, carrying one AU4 service in an embodiment of this application.

[0054] Figure 41 is a schematic diagram of the VC4 business structure according to an embodiment of this application;

[0055] Figure 42 is a flowchart illustrating a method for carrying out an embodiment of this application;

[0056] Figure 43 is a flowchart illustrating a method for carrying out an embodiment of this application;

[0057] Figure 44 is a schematic diagram of the structure of an electronic device according to an embodiment of this application;

[0058] Figure 45 is a structural schematic diagram of a carrier device according to an embodiment of this application;

[0059] Figure 46 is a schematic diagram of the structure of a carrier device according to an embodiment of this application. Detailed Implementation

[0060] The rapid increase in user network traffic has spurred the rapid development of communication network bandwidth. The interface bandwidth of communication equipment has increased from 10 Mbps (bits per second) to 100 Mbps, then further increased by 1 Gbps and 10 Gbps, currently reaching 100 Gbps. 100 Gbps optical modules are now widely used in the market. While 400 Gbps optical modules have been developed, their high price—exceeding the cost of four 100 Gbps modules—affects their commercial economic value. To transmit 400 Gbps services over 100 Gbps optical modules, the international standards organization defined the FlexE protocol. The FlexE protocol combines multiple 100 Gbps optical modules to form a high-speed transmission channel. As shown in Figure 1, combining four 100 Gbps optical modules using the FlexE protocol can form a 400 Gbps transmission channel, equivalent to the transmission speed of a single 400 Gbps module, thus solving the 400 Gbps service transmission requirement without increasing costs.

[0061] For 100G physical layer services, the Ethernet protocol defines that before sending a 100G data packet, the data packet is 64 / 66 encoded, expanding the 64-bit data block into a 66-bit information block. The added 2 bits are placed at the beginning of the 66-bit block as a start marker, and then it is sent out from the optical interface in 66-bit blocks. Upon reception, the optical interface identifies the 66-bit blocks from the received data stream, then recovers the original 64-bit data from the 66-bit blocks and reassembles the data packet. The FlexE protocol, located below the 64-bit to 66-bit block conversion layer, sorts and plans the 66-bit data blocks before sending them. As shown in Figure 2, for 100G services, every 20 66-bit data blocks are divided into a block group, with each group containing 20 blocks, representing 20 time slots, each time slot representing a service speed of 5G (bit / s) bandwidth. When sending 66-bit data blocks, a FlexE overhead block (the black block in Figure 2) is inserted after every 1023 data block groups (1023 * 20 data blocks). After inserting the overhead block, data blocks continue to be sent. After sending the second 1023 * 20 data blocks, another overhead block is inserted, and so on. In this way, overhead blocks are periodically inserted during data block transmission, with an interval of 1023 * 20 data blocks between adjacent overhead blocks. For a service with a physical line speed of 100 Gbps, the FlexE protocol divides the physical port into 20 time slots, so each time slot corresponds to a bandwidth of 5 Gbps.

[0062] The FlexE protocol defines a sufficient number of time slots and bandwidth to meet the transmission needs of customer services such as routers and Optical Transport Networks (OTN). However, its application in Packet Transport Networks (PTN) presents several challenges: 1. A 100G physical channel has only 20 time slots, which is too few; 2. Each time slot has a bandwidth of 5G, resulting in excessively large granularity. The FlexE protocol suffers from both a limited number of time slots and excessively large granularity, defining a time slot as a small number of slots with high granularity. In contrast, PTN services involve numerous customer services with relatively small bandwidth per service, resulting in a large number of time slots and low granularity for each slot. This makes the FlexE protocol unsuitable for PTN application scenarios.

[0063] To address the needs of customer services operating at speeds lower than 5G, communication network operators have defined fine-grained slicing technical requirements for packet slicing networks and proposed a fine-grained frame structure. This fine-grained frame structure consists of S-blocks, D-blocks, and T-blocks. These are coded blocks defined by Ethernet. Figure 3 shows the 64 / 66 encoding rules of the Ethernet 802.3 protocol. Each block consists of 66 bits, with the first two bits being the block's synchronization header. A synchronization header bit of "01" indicates that the block is a D-block (data block), followed by 8 bytes (64 bits) of data content. A synchronization header bit of "10" indicates that the block is a control block. The first byte after the synchronization header bit of a control block indicates the type of control block, and the following 7 bytes contain the control block content, determined by the control block type.

[0064] As shown in Figure 3, S-blocks, T-blocks, O-blocks, and idle blocks (also called IDLE blocks, I-blocks, or I-blocks) all belong to control blocks. The first byte of an S-block is 0x78, indicating that the control block type is S-block. An S-block represents the first block in a data packet block stream. A T-block represents the last block in a data packet block stream; it is the end-of-message block. Besides indicating the end-of-message block, a T-block can also carry client byte content (located in the last 7 bytes of the block). In the Ethernet standard, T-blocks are divided into eight types: T0, T1, T2, T3, T4, T5, T6, and T7. The first byte of a T0 block is 0x87, and it does not carry client information (or client content). The first byte of a T1 block is 0x99, and it carries one byte of client information. The first byte of a T2 block is 0xAA, and it carries two bytes of client information. The first byte of a T3 block is 0xB4, and it carries three bytes of client information. The first byte of a T4 block is 0xCC, and it carries four bytes of client information. The first byte of a T5 block is 0xD2, and it carries five bytes of client information. The first byte of a T6 block is 0xE1, and it carries six bytes of client information. The first byte of a T7 block is 0xFF, and it carries seven bytes of client information. The IDLE block (also known as the I block) is an idle block or error indicator block, and its first byte (i.e., control word content) is 0x1E. The 0 block is a maintenance and management block, and its first byte is 0x4B.

[0065] Currently, different standards both domestically and internationally have established different fine-grained frame (also known as fine-grained bearer frame, small-grained bearer frame, or small-grained frame) formats. Figure 4 shows the fine-grained frame structure developed by China Mobile. This fine-grained frame consists of one S-block, 195 D-blocks, and one T-block. The D-block within a fine-grained frame is divided into overhead byte information and 24 sub-time slots. Every 20 fine-grained frames form a multiframe, with 480 sub-time slots in one multiframe period. Figure 5 shows the fine-grained frame structure in a standard document being developed by the International Telecommunication Union (ITU). This fine-grained frame consists of one S-block, 990 D-blocks, and one T-block. The D-block within a fine-grained frame is divided into overhead byte information and 480 sub-time slots. 480 fine-grained frames form a multiframe, with each frame in the multiframe transmitting the overhead information for one time slot. The overhead information for all 480 sub-time slots is transmitted through the 480 fine-grained frames in one multiframe.

[0066] The fine-grained frames shown in Figures 4 and 5 can be carried on 5G speed time slots of the FlexE interface. Each fine-grained frame is divided into 480 sub-slots, effectively dividing the transport pipeline of a 5G speed time slot into 480 sub-slots. Each sub-slot has a bandwidth of 10Mbps (actually slightly higher than 10Mbps). Therefore, one sub-slot of a fine-grained frame can carry 10Mbps customer services, basically meeting the transport requirements of ordinary Ethernet services (currently, Ethernet service bandwidths are 10Mbps, 100Mbps, 1Gbps and above; services greater than 10Mbps use multiple sub-slots). When a fine-grained sub-slot carries a 10Mbps customer service, the 10Mbps customer service is first 64 / 66 encoded. After encoding, it is carried on a portion of the sub-slots, and then the fine-grained frame is mapped to a FlexE protocol time slot and sent out, transmitted to the remote destination device via the 5G speed time slots of the FlexE protocol.

[0067] The aforementioned fine-grained slicing technology for packet slicing is required to support customer services at speeds of up to 10 Mbps. However, in some application scenarios, the equipment needs to replace SDH equipment and support services in the SDH system standard, such as TU12, VC12, AU4, or VC4 services. Currently, there is no relevant solution to support these services.

[0068] This application proposes a bearer frame, a bearer method, an electronic device, a storage medium, and a program product. The bearer frame consists of S-blocks, D-blocks, and T-blocks. The bearer frame includes an overhead area and a bearer area. The overhead area carries overhead information, and the bearer area carries the client content of the first service. Idle blocks are inserted between multiple bearer frames before being mapped to sub-time slots in the service layer for transmission. One bearer frame can carry one or more first services. Thus, when carrying services in the SDH architecture standard (such as TU12, VC12, AU4, or VC4 services) in sub-time slots based on the FlexE protocol standard, one or more services to be carried can be mapped to a bearer frame. Then, idle blocks are inserted between multiple bearer frames before being mapped to sub-time slots for transmission. This enables the carrying of services in the SDH architecture standard, meeting the service carrying requirements.

[0069] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in this application will be clearly and completely described below with reference to the accompanying drawings of one or more embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this application.

[0070] The terms "first," "second," etc., used in this application and the claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that this application can be implemented in orders other than those illustrated or described herein. Furthermore, in this application and the claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0071] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0072] Figure 6 is a schematic diagram of a carrier frame according to an embodiment of this application.

[0073] As shown in Figure 6, the bearer frame provided in this embodiment consists of S-blocks, D-blocks, and T-blocks. The S-blocks, D-blocks, and T-blocks are 66-bit blocks as defined by the Ethernet 802.3 international standard. The S-block is the start block of the bearer frame, and there is one S-block. The D-block is the middle block of the bearer frame; it is a data block and can be used to carry client content. One D-block can carry 8 bytes of client content, and the number of D-blocks is n-2 (n is an integer greater than 2), which can be determined according to the client content to be carried. The T-block is the end block of the bearer frame, and there is one T-block. Specifically, it can be any one of the T0, T1, T2, T3, T4, T5, T6, and T7 blocks defined in the Ethernet standard.

[0074] The bearer frame includes an overhead area and a bearer area (not shown in Figure 6). The overhead area carries the overhead information (which can be represented as OH, i.e., overhead) for the first service. The overhead information represents the characteristic information of the bearer frame structure. The overhead area can include multiple bytes, such as 2 bytes, 3 bytes, 4 bytes, 5 bytes, 6 bytes, or 7 bytes, etc., without specific limitations. The overhead area can be located in the S-block, or in the D-block (e.g., in the first D-block), or in both the S-block and D-block (e.g., in both the S-block and the first D-block), without specific limitations. The bearer area carries the client content of the first service. The bearer area can include multiple bytes, the specific number of which can be determined according to the actual client content to be carried, without specific limitations. The bearer area can be located in the S-block, D-block, and T-block, or in the D-block and T-block, or in the S-block and D-block, or only in the D-block, without specific limitations.

[0075] The bearer frames shown in Figure 6 can be mapped to sub-time slots in the service layer for transmission. One bearer frame can carry one or more primary services. For multiple bearer frames, idle code blocks can be inserted between them before mapping to sub-time slots in the service layer for transmission. When inserting idle code blocks between multiple bearer frames, idle code blocks can be inserted periodically every one or more bearer frames, or non-periodically; no specific limitation is made here. When inserting idle code blocks, one or multiple idle code blocks can be inserted, depending on the actual service requirements; no specific limitation is made here.

[0076] The first service refers to the services defined in the SDH architecture standard. In some implementations, the first service may specifically be a TU12 service, a VC12 service, an AU4 service, or a VC4 service. Specifically, when the first service is a TU12 service, one bearer frame can be used to carry one or more TU12 services. When the first service is a VC12 service, one bearer frame can be used to carry one or more VC12 services. When the first service is an AU4 service, one bearer frame can be used to carry one AU4 service. When the first service is a VC4 service, one bearer frame can be used to carry one VC4 service.

[0077] In some implementations, the overhead information carried in the overhead area may include at least one of the following: SDH frame overhead content, used to carry regenerator section layer and multiplexer section layer overhead; multiframe indicator, used to indicate the sequential relationship of multiple bearer frames in a multiframe group; service type (also known as customer type), used to characterize the service type carried by the bearer frame; customer number, used to distinguish different bearer frames carrying different customer services; adjustment indicator, used to indicate whether the adjustment area of ​​the bearer area carries customer content; and a Cyclic Redundancy Check (CRC) field.

[0078] The multiframe indication, service type, customer number, and CRC fields can each include one or more bytes, without specific limitations.

[0079] A multiframe group can include multiple bearer frames. For a single bearer frame, when it forms a multiframe group with other bearer frames, its overhead information can include a multiframe indicator. The multiframe indicator can be represented by a sequence value, such as frame 0, frame 1, frame 2, frame 3, etc. Alternatively, the multiframe indicator can be represented in other ways, which will not be illustrated here.

[0080] Different bearer frames can carry the primary services of different customers. When multiple bearer frames carry the primary services of multiple customers, the overhead information of each bearer frame can include a customer number to distinguish different bearer frames carrying different customer services by the customer number.

[0081] The service type is used to indicate the type of customer service carried by the bearer frame. For a bearer frame carrying the first service, the overhead information may include the customer type to indicate that the service type carried by the bearer frame is the first service, and not any other service. For example, for a bearer frame carrying the TU12 service, the overhead information may include the service type to indicate that the service type carried by the bearer frame is the TU12 service, and not other types of customer services such as TU11, TU3, AU3, AU4, etc.

[0082] It should be noted that in practical applications, the overhead information carried in the overhead area can be any one or more of the above six types of overhead information, depending on the actual business needs, and no specific limit is made here. The number of bytes occupied by each type of overhead information can also be determined according to the actual business needs, and no specific limit is made here either.

[0083] In some implementations, the bearer region may include a fixed stuffing region (also called a stuffing region, fixed padding region, or padding region), an adjustment region (also called a bearer adjustment region), and a fixed bearer region. The fixed stuffing region carries fixed padding content and does not carry client content. In specific implementations, the fixed stuffing region is an invalid region that does not carry client content and can be set as needed. For example, when the bearer region in the bearer frame is too large, some fixed stuffing regions can be set to reduce the number of bytes used to carry client content in the bearer region, i.e., reduce the number of bytes carried in the effective bearer region. The fixed stuffing region can be located in an S-code block or a D-code block, and the number of bytes can be zero or more. Zero indicates no fixed stuffing region, meaning the bearer region size of the bearer frame exactly matches the required number of bytes to carry, there is no issue of it being too large, and there is no need to set a fixed stuffing region to reduce the size of the effective bearer region.

[0084] The adjustment area can be located in the S-block, the D-block, or both. It may or may not carry client content, and the content carried by the adjustment area can be indicated by the adjustment instruction information in the overhead information. Since the adjustment area may or may not carry client content, it can be used to adjust the number of bytes carrying client content. Whether the adjustment area carries client content depends on the required client service speed and is not specifically limited here. The adjustment area can include one or more bytes. When the adjustment area includes multiple bytes, some or all of them can carry (or not carry) client content; this is not specifically limited here. When some bytes carry (or not carry) client content, these bytes can be located anywhere within the adjustment area; this is also not specifically limited here. For example, if the adjustment area includes two bytes, and one byte carries client content while the other does not, the first byte can carry client content while the second does not, or vice versa. In practice, it can be determined whether to carry customer content in the adjustment area based on the speed of the customer services that need to be carried, and the overhead information in the overhead area indicates the number of bytes used to carry customer content in the adjustment area.

[0085] The entire area of ​​the fixed bearer region is used to carry customer content and is not affected by the speed of customer services. The fixed bearer region may include multiple bytes, which may be located in D code blocks, or in S code blocks and D code blocks, or in D code blocks and T code blocks, or in S code blocks, D code blocks and T code blocks.

[0086] Figure 7 is a schematic diagram of a bearer frame according to an embodiment of this application. The bearer frame shown in Figure 7 consists of one S-block, n-2 (n is an integer greater than 2) D-blocks, and one T-block, where the T-block is a T7 block. The overhead area (OH) is located in the first D-block and includes 5 bytes (in other embodiments, the number of bytes can be different; 5 bytes are used as an example here). The remaining bytes in the D-block and the last 7 bytes in the T-block constitute the bearer area. The overhead information carried in the overhead area may include six fields: multiframe indication, service type, customer number, SDH overhead bytes, adjustment indication, and CRC checksum, as shown in Figure 8. Of course, in other implementations, the overhead information may include any one or more of these six fields; no specific limitation is made here. The bearer area carries customer content, such as customer content for TU12 service, VC12 service, AU4 service, or VC4 service. The bearer area includes a Stuffing (STF) area, a Negative Adjustment Opportunity (NJO) area, and a fixed bearer area (the blank byte area in Figure 7). The Stuffing area in Figure 7 includes 2 bytes, and the Adjustment area includes 1 byte. In other embodiments, the number of bytes occupied by the Stuffing area and the Adjustment area can also be other values, which are not specifically limited here.

[0087] It should be noted that in some implementations, the overhead region shown in Figure 7 can also be located within the S-code block, which reduces one D-code block and thus the length of the bearer frame. As shown in Figure 9, the bearer frame shown in Figure 9 has one less D-code block than the bearer frame shown in Figure 7, totaling n-1 code blocks. The overhead region is located within the S-code block and comprises 5 bytes. The bearer region includes a one-byte fixed insertion area, a one-byte adjustment area, and multiple bytes of fixed bearer area (i.e., the blank byte area shown in Figure 9).

[0088] In some implementations, the bearer frame may also include a specific byte position value. This specific byte position value may be located in the overhead area, or after the overhead area and before the bearer area (i.e., between the overhead area and the bearer area), or at the beginning of the bearer area; no specific limitation is made here.

[0089] A specific byte position value may or may not be within the valid range of the bearer frame (i.e., it may exceed the valid range of the bearer frame). When the specific byte position value is within the valid range of the bearer frame, it can be used to indicate the position of the specific byte of the first service within the bearer area. When the specific byte position value is outside the valid range of the bearer frame, it can be used to indicate other meanings. In some implementations, the specific byte position value exceeding the valid range of the bearer frame can have many different preset values, each representing a different preset meaning. For example, a preset position value 1 exceeding the valid range of the bearer frame can indicate that the current frame does not carry the specific byte content of the customer; a preset position value 2 exceeding the valid range of the bearer frame can indicate that the current frame does not carry the customer service; a preset position value 3 exceeding the valid range of the bearer frame can indicate a customer service failure, and so on. These will not be listed in detail here.

[0090] The specific byte for the first service can be V1 byte, V5 byte, H1 byte, or J1 byte. Specifically, when the first service is TU12, the specific byte is V1 byte. When the first service is VC12, the specific byte is V5 byte. When the first service is AU4, the specific byte is H1 byte. When the first service is VC4, the specific byte is J1 byte.

[0091] When a specific byte of the first service is carried in the bearer frame, the specific byte of the first service can be carried at a fixed position in the bearer area or at a dynamically changing position in the bearer area. That is, the position of the specific byte of the first service in the bearer area can be fixed or changing. If the position value of the specific byte is within the effective range of the bearer frame, it can indicate the specific position of the specific byte of the first service in the bearer area.

[0092] Specific byte position values ​​can include one set or multiple sets of specific byte position values. Specifically, when a bearer frame is used to carry one primary service, the specific byte position values ​​can include one set of specific byte position values, which are used to indicate the position of a specific byte in the bearer area for this primary service. When a bearer frame is used to carry multiple primary services, the specific byte position values ​​can include one set or multiple sets of specific byte position values. When including one set of specific byte position values, this set is used to indicate the position of a specific byte in the bearer area for different primary services at different times using time-division multiplexing. For example, in each frame of a multiframe, the specific byte position values ​​can indicate the position of a specific byte of one of multiple customers in the bearer frame. When including multiple sets of specific byte position values, each set of specific byte position values ​​is used to indicate the position of a specific byte in the bearer area for the corresponding primary service.

[0093] A specific byte position value can be a numerical value of multiple bits (the exact number can be determined according to actual needs), a pointer value of 1 byte, or a pointer value of 2 bytes. When the specific byte position value is a pointer value of 1 byte, this pointer value can be either a V byte or an H byte; that is, the specific byte position value can be simply referred to as V byte or H byte. When the specific byte position value is a pointer value of 2 bytes, these 2 bytes can be either V1 bytes and V2 bytes, or H1 bytes and H2 bytes; that is, the specific byte position value can be simply referred to as V1 bytes and V2 bytes, or H1 bytes and H2 bytes.

[0094] Figure 10 is a schematic diagram of a specific byte being carried at a fixed position in the bearer area according to an embodiment of this application. The specific byte in Figure 10 is carried at the first byte position of the client content in the bearer area, that is, the specific byte position is the first byte position after the Fixed Insertion Area (STF) shown in Figure 10.

[0095] Figure 11 is a schematic diagram of a specific byte position value indicating the position of a specific byte in the bearer area according to an embodiment of the present application. The specific byte in Figure 11 is carried at a dynamically changing position in the bearer area (the fixed insertion area, adjustment area or fixed bearer area in the bearer area is not shown in Figure 11), which can be indicated by the specific byte position value in the overhead area (the specific byte position value is not shown in the overhead area in Figure 11).

[0096] Figure 12 is a schematic diagram illustrating the position of a specific byte in the bearer area according to an embodiment of this application. The specific byte in Figure 12 is carried at a dynamically changing position in the bearer area, which can be indicated by the specific byte position value between the overhead area and the bearer area. The specific byte position value occupies a total of 2 bytes (in other embodiments, it may occupy multiple bits or 1 byte; Figure 12 is illustrated using only 2 bytes as an example). The first byte of the bearer area shown in Figure 12 can be the first byte of a fixed insertion area, the first byte of an adjustment area, or the first byte of a fixed bearer area; no specific limitation is made here.

[0097] Figure 13 is a schematic diagram illustrating the position of a specific byte in the bearer area according to an embodiment of this application. The specific byte in Figure 13 is carried at a dynamically changing position in the bearer area, which can be indicated by the specific byte position value located at the beginning of the bearer area. The specific byte position value occupies 2 bytes (in other embodiments, it may occupy multiple bits or 1 byte; Figure 13 only illustrates this with 2 bytes as an example). The first byte after the specific byte position value is the adjustment area (NJO), which may or may not carry client content. Of course, in other embodiments, the first byte after the specific byte position value may also be a fixed insertion area or a fixed bearer area; this is not specifically limited here.

[0098] When the bearer frame is used to carry TU12 services, the specific byte in Figures 10 to 13 is byte V1. When the bearer frame is used to carry VC12 services, the specific byte in Figures 10 to 13 is byte V5. When the bearer frame is used to carry AU4 services, the specific byte in Figures 10 to 13 is byte H1. When the bearer frame is used to carry VC4 services, the specific byte in Figures 10 to 13 is byte J1. Furthermore, when the bearer frame is used to carry either TU12 or VC12 services, the specific byte position values ​​in Figures 12 and 13 can be bytes V1 and V2. When the bearer frame is used to carry either AU4 or VC4 services, the specific byte position values ​​in Figures 12 and 13 can be bytes H1 or H2.

[0099] In some implementations, when a single bearer frame carries multiple first services, these multiple first services can share the S-block, T-block, and overhead area of ​​the bearer frame and have independent adjustment and fixed bearer areas. For example, if the first service is a TU12 service, and a single bearer frame carries multiple TU12 services, these multiple TU12 services can share the S-block, T-block, and overhead area of ​​the bearer frame and have independent adjustment and fixed bearer areas. As another example, if the first service is a VC12 service, and a single bearer frame carries multiple VC12 services, these multiple VC12 services can share the S-block, T-block, and overhead area of ​​the bearer frame and have independent adjustment and fixed bearer areas.

[0100] Optionally, in some implementations, when a bearer frame is used to carry multiple first services, each of the multiple first services may also have an independent adjustment indication. For example, if the first service is a TU12 service, and a bearer frame carries multiple TU12 services, each of the multiple TU12 services may have an independent adjustment indication to indicate whether the adjustment area corresponding to each TU12 service carries client content. As another example, if the first service is a VC12 service, and a bearer frame carries multiple VC12 services, each of the multiple VC12 services may have an independent adjustment indication to indicate whether the adjustment area corresponding to each VC12 service carries client content.

[0101] TU12 is a unit structure defined in SDH, as shown in Figure 14. TU12 consists of four bytes (V1, V2, V3, and V4) and 140 VC12 bytes. The four bytes (V1, V2, V3, and V4) are evenly spaced, with a 35-byte interval between adjacent bytes. Byte V1 is the first byte in TU12. When TU12 is mapped to a bearer frame for transmission, the transmitting end can place the V1 byte in a fixed position. This allows the receiving end to determine the position of the V1 byte in a TU12 unit, i.e., the start position of the TU12, and thus determine the positions of all bytes in the TU12 (the 144 bytes starting from V1 belong to the same TU12), distinguishing each TU12 unit from all the client bytes carried. When TU12 is mapped to a bearer frame for transmission, with the adjustment area enabled, the adjustment area may or may not carry TU12 bytes. Therefore, the position of byte V1 in each frame is dynamically changing. Specific byte position values ​​from the overhead information are needed to indicate the position of a specific byte (such as byte V1) in the bearer frame, allowing the receiver to determine the true position of byte V1 in each frame. Furthermore, with the adjustment area enabled, adjustment indication information from the overhead information is also needed to indicate whether the adjustment area carries customer services. The contents of V1 and V2 in TU12 are pointer values ​​used to indicate the position of byte V5 in VC12, i.e., the distance between byte V5 and byte V2. In Figure 14, V5 is two bytes after V2, so the pointer value of V1V2 equals 2.

[0102] Figure 15 is a schematic diagram of the structure of a bearer frame in an embodiment of this application when carrying TU12 services. The bearer shown in Figure 15 includes an overhead area (OH) and a bearer area. The bearer area includes a fixed stuff area (STF) and a fixed bearer area, but does not include an adjustment area. The V1 byte of the TU12 service is carried at a fixed position in the bearer area (i.e., the first byte position after the fixed stuff area).

[0103] Figure 16 is a schematic diagram of the structure of a bearer frame in an embodiment of this application when carrying TU12 services. The bearer frame shown in Figure 16 includes an overhead area (OH) and a bearer area. The bearer area includes a fixed stuffing area (STF), an adjustment area (NJO), and a fixed bearer area. The V1 byte of the TU12 service is carried in a dynamically changing position in the bearer area, and the actual position of the V1 byte is indicated by a specific byte position value in the overhead area.

[0104] It should be noted that in other possible implementations, the structure of the bearer frame used to carry TU12 services can also be in other forms. For example, the overhead area of ​​Figure 15 or Figure 16 can be set in the S code block and one D code block can be reduced. These will not be illustrated here.

[0105] The TU12 service shown in Figure 14 consists of four groups of bytes. Each group includes one V byte (V1, V2, V3, or V4) and 35 VC12 bytes, totaling 36 bytes per group and 144 bytes in total. The first byte of the TU12 service is the V1 byte. The speed of the TU12 service is 2.304M (bit / s), while the pipeline speed of a sub-slot of a fine-grained frame in the service layer is 10M (bit / s; in some scenarios, it may be higher, such as 10.1M). Therefore, a sub-slot in a fine-grained frame can carry a maximum of four TU12 services, that is, one, two, three, or four TU12 services can be carried in one sub-slot. When a sub-time slot carries one TU12 service, the corresponding carrying efficiency needs to be at least 1*2.304 / 10 = 23.04% (22.81% when the sub-time slot speed is calculated at 10.1M). When a sub-time slot carries two TU12 services, the corresponding carrying efficiency needs to be at least 2*2.304 / 10 = 46.08% (45.62% when the sub-time slot speed is calculated at 10.1M). When a sub-time slot carries four TU12 services, the corresponding carrying efficiency needs to be at least 3*2.304 / 10 = 69.12% (68.43% when the sub-time slot speed is calculated at 10.1M). When a sub-time slot carries four TU12 services, the corresponding carrying efficiency needs to be at least 4*2.304 / 10 = 92.16% (91.24% when the sub-time slot speed is calculated at 10.1M).

[0106] When a bearer frame is used to carry one or more TU12 services, the encapsulation mode of the bearer frame can include the following two modes: Independent encapsulation mode: a bearer frame carries only one TU12 service, multiple bearer frame streams carry multiple TU12 services respectively, and multiple bearer frame streams are interleaved and transmitted through a sub-time slot; Co-encapsulation mode: a bearer frame is divided into multiple partitions, each partition carries one TU12 service, a bearer frame carries multiple TU12 services at the same time, and the bearer frame is transmitted directly through a sub-time slot.

[0107] In independent encapsulation mode, each TU12 service is independently encapsulated in its own bearer frame; that is, one TU12 service from a single customer is independently encapsulated in one bearer frame. In co-encapsulation mode, multiple TU12 services are encapsulated in one bearer frame, meaning all or part of the TU12 services from multiple customers are encapsulated in one bearer frame. Furthermore, in co-encapsulation mode, multiple TU12 services can share the S-block, T-block, and overhead area of ​​the bearer frame and have independent adjustment and fixed bearer areas. Optionally, the multiple TU12 services can also have independent adjustment indicators. Optionally, the multiple TU12 services can have the same or independent specific byte position values.

[0108] In practical applications, under independent encapsulation mode, when mapping multiple bearer frames carrying multiple TU12 services (one bearer frame carries one TU12 service, and different TU12 services are carried in different bearer frames; in this case, one bearer frame can be represented as one bearer frame) to sub-time slots for transmission, these multiple TU12 services can be mapped to a single sub-time slot for transmission. When mapping multiple bearer frames to a single sub-time slot for transmission, the multiple bearer frames can be interleaved and mapped to a single sub-time slot. There are two interleaving methods: one is to interleave the multiple bearer frames sequentially frame-by-frame before mapping to a single sub-time slot; the other is to interleave them sequentially block-by-block. The frame-by-frame interleaving method ensures that the transmission delay time of each customer service is equal. The block-by-block interleaving method not only ensures that the delay time of each customer's TU12 service is equal but also reduces the encapsulation delay time of the TU12 service.

[0109] Figure 17 is a schematic diagram of an embodiment of this application, illustrating the interleaving and mapping of four TU12 bearer frames into a sub-time slot. As shown in Figure 17, for one bearer frame each from customer 1, customer 2, customer 3, and customer 4 (a total of four bearer frames), the four bearer frames can be interleaved in the order of customer 1, customer 2, customer 3, and customer 4 to obtain a bearer frame stream. After obtaining a bearer frame stream, an appropriate number of idle code blocks (IDLE blocks, I blocks, etc.) can be inserted between the interleaved bearer frames. Idle code blocks are used for speed adjustment during subsequent transmission. Subsequent network devices adjust the speed of the bearer frames by adding or deleting some IDLE blocks so that the speed of the bearer frames matches the network clock frequency. To monitor the network performance of the service layer, Operation Administration and Maintenance (OAM) code blocks (O blocks) can be inserted between the bearer frames for performance monitoring. After inserting idle code blocks and OAM code blocks between the bearer frames, they can be mapped into a sub-time slot for transmission. By interleaving each bearer frame on a frame-by-frame basis, the transmission delay time of each client service can be made equal. Specifically, when interleaving four bearer frames on a frame-by-frame basis, interleaving can only be performed after each bearer frame has been fully encapsulated. The delay time of each client service is the encapsulation completion time of one bearer frame. Encapsulating a 144-byte TU12 service takes 500µs, therefore the encapsulation delay time of each TU12 service is 500µs.

[0110] Figure 18 is a schematic diagram of an embodiment of this application, in which four TU12 bearer frames are interleaved and mapped to a sub-time slot in units of code blocks. As shown in Figure 18, for one bearer frame each of customer 1, customer 2, customer 3 and customer 4 (a total of 4 bearer frames), the 4 bearer frames can be interleaved in units of code blocks according to the order of customer 1, customer 2, customer 3 and customer 4 to obtain a set of code block streams. In this group of code block streams, the order of each code block is as follows: S code block of the first TU12 bearer frame, S code block of the second TU12 bearer frame, S code block of the third TU12 bearer frame, S code block of the fourth TU12 bearer frame, D code block of the first TU12 bearer frame, D code block of the second TU12 bearer frame, D code block of the third TU12 bearer frame, D code block of the fourth TU12 bearer frame, D code block of the first TU12 bearer frame, D code block of the second TU12 bearer frame, D code block of the third TU12 bearer frame, D code block of the fourth TU12 bearer frame, ..., T code block of the first TU12 bearer frame, T code block of the second TU12 bearer frame, T code block of the third TU12 bearer frame, and T code block of the fourth TU12 bearer frame. After obtaining the code block stream, a suitable amount of idle code blocks and OAM code blocks can be inserted into the code block stream, and then mapped onto fine-grained sub-time slots for transmission. Specifically, when interleaving the four bearer frames in units of code blocks, it is not necessary to wait until each TU12 bearer frame is fully encapsulated before initiating interleaving. Instead, interleaving can begin as soon as each TU12 bearer frame completes part of its encapsulation. In other words, TU12 bearer frames can be encapsulated and interleaved simultaneously, completing one frame of interleaving at the end of encapsulation. This results in very low encapsulation latency for each TU12 service, typically the latency of two or three code blocks. Compared to frame-based interleaving, this reduces latency by at least 10 times, reaching the order of magnitude of SDH encapsulation latency.

[0111] For the interleaving method shown in Figure 17, at the receiving end, upon receiving a fine-grained sub-time slot carrying the bearer frame stream, as shown in Figure 19, the bearer frame stream can be extracted from the fine-grained sub-time slot. Then, the OAM code blocks and idle code blocks in the bearer frame stream are stripped off, and finally, deinterleaving is performed frame by frame, thus obtaining 4 bearer frames. After obtaining the 4 bearer frames, the customer's TU12 service can be extracted from the bearer frames.

[0112] For the interleaving method shown in Figure 18, at the receiving end, when a fine-grained sub-time slot carrying a code block stream is received, as shown in Figure 20, the code block stream can be extracted from the fine-grained sub-time slot. Then, the OAM code blocks and idle code blocks in the code block stream are stripped off. The remaining code blocks are all composed of S code blocks, D code blocks, and T code blocks. At this time, deinterleaving can be performed on a code block basis. Every 4 S code blocks, every 4 D code blocks, and every 4 T code blocks are deinterleaved into 4 groups. The S code blocks, D code blocks, and T code blocks in the same group are combined and the TU12 bearer frame is recovered, thus obtaining 4 bearer frames. After obtaining the four bearer frames, the customer's TU12 service can be extracted from the bearer frames.

[0113] The length of a bearer frame is a crucial characteristic, determining its carrying efficiency. The carrying efficiency equals the ratio of the number of bytes used to carry client traffic to the total number of bytes in the bearer frame. Since the overhead area, fixed-insertion area, control word portion of the S-block, and control word portion of the T-block do not carry client traffic, the carrying efficiency is less than 100%. Generally, the more D-blocks in the bearer frame, the longer the frame, the more bytes used for client traffic, and the higher the carrying efficiency. In actual TU12 service carrying, the carrying efficiency requirement can be determined based on the client speed of the required TU12 service and the number of selected service layer sub-slots (the number of service layer sub-slots is equivalent to the total service layer rate). Based on the carrying efficiency requirement, the number of D-blocks in the bearer frame is determined, thus determining the frame length and ultimately the format.

[0114] The following will use some more specific implementation examples to illustrate the possible frame structure of a bearer frame when it carries one or more TU12 services.

[0115] In some implementations, when a bearer frame is used to carry one TU12 service, a bearer frame may consist of one S-block, 17 D-blocks and one T-block, with the overhead area located in the S-block and the bearer area located in the S-block, D-block and T-block. The bearer area may include a 144-byte fixed bearer area or include a 1-byte adjustment area and a 143-byte fixed bearer area.

[0116] Taking the bearer frame shown in Figures 21 and 22 as an example, the bearer frame shown in Figure 21 consists of one S-block, 17 D-blocks, and one T-block. The overhead area (OH) is located in the S-block and has 5 overhead bytes. The bearer area is located in the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF) and a 144-byte fixed bearer area. The V1 byte is carried at a fixed position in the bearer area, as shown in Figure 21, where the V1 byte is located at the last byte position in the S-block. The bearer frame shown in Figure 21 can adopt the above-described independent encapsulation mode.

[0117] The bearer frame shown in Figure 22 consists of one S-block, 17 D-blocks, and one T-block. The overhead (OH) region is located within the S-block and contains 5 overhead bytes. The bearer region is located within the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF), a 1-byte adjustment area (NJO), and a 143-byte fixed bearer region. The position of the V1 byte within the bearer region is not fixed; that is, the V1 byte is carried in a dynamically changing position within the bearer region. The position of the V1 byte may differ in each frame, requiring a specific byte position value to indicate its accurate location. The bearer frame shown in Figure 22 can employ the aforementioned independent encapsulation mode.

[0118] In some implementations, when a bearer frame is used to carry four TU12 services, the bearer frame may consist of one S-block, 17 D-blocks, and one T-block. The overhead area of ​​the bearer frame is located in the S-block, and the bearer area is located in the S-block, D-block, and T-block. The bearer area is divided into four groups, each including a 36-byte fixed bearer area or including a 1-byte adjustment area and a 35-byte fixed bearer area.

[0119] Taking the bearer frames shown in Figures 23 and 24 as examples, the bearer frame shown in Figure 23 consists of one S-block, 17 D-blocks, and one T-block. The overhead area (OH) is located in the S-block and has 5 overhead bytes. The bearer area is located in the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF) and a 144-byte fixed bearer area. The 144-byte fixed bearer area is divided into 4 groups (each group is indicated by a subscript number: group 1, group 2, group 3, group 4), with each group containing 36 bytes. Each group carries 36 bytes of one TU12 service, and four consecutive frames carry 144 bytes of each TU12 service. Since each frame only carries 36 bytes of each TU12 service, each frame may contain one of the bytes V1, V2, V3, and V4. Regardless of which byte V1-V4 it is, it is located in a fixed position. In implementation, the multiframe number can indicate which byte (V1-V4) is carried in the current frame. For example, it can be agreed that multiframe number 0 carries byte V1, multiframe number 1 carries byte V2, multiframe number 2 carries byte V3, multiframe number 3 carries byte V4, multiframe number 4 carries byte V1, multiframe number 5 carries byte V5, and so on. Alternatively, a specific byte position value can be used to indicate whether the frame carries byte V1 and its position. For instance, when the specific byte position value is within the valid range of the carrying frame, it indicates that the current frame carries byte V1, and the value is the position of byte V1. For example, a specific byte position value of 1 indicates that the current frame carries byte V1, and byte V1 is located at the first byte position in the fixed carrying area. When a specific byte position value is outside the valid range of the carrier frame, it indicates that the frame does not carry the V1 byte. For example, when the specific byte position value is 255 (the maximum value that 8 bits can represent, and the valid range of the specific byte position value is 1-144), it exceeds the valid range of 1-144, which means that the frame does not carry the V1 byte. The carrier frame shown in Figure 23 can adopt the co-encapsulation mode described above.

[0120] The bearer frame shown in Figure 24 consists of one S-block, 17 D-blocks, and one T-block. The overhead (OH) region is located within the S-block and contains 5 overhead bytes. The bearer region is located within the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF), a 1-byte adjustment area (NJO), and a 143-byte fixed bearer region. The position of the V1 byte within the bearer region is not fixed; that is, the V1 byte is carried in a dynamically changing position within the bearer region. The position of the V1 byte may differ in each frame, requiring a specific byte position value to indicate its accurate location. The bearer frame shown in Figure 24 can employ the aforementioned co-encapsulation mode.

[0121] In the co-encapsulation, V1 fixed-position mode shown in Figure 23, multiple TU12 services are carried within a single bearer frame, and the V1 bytes of all TU12 services are carried in a fixed position. This requires all TU12 services to maintain the same speed and phase position before being carried, i.e., the V1 bytes arrive simultaneously. When all TU12 services come from the same STM-1 (or STM-4, STM-16, STM-64), the speed and phase position of all TU12 services are the same. However, when all TU12 services come from different STM-1 (or STM-4, STM-16, STM-64) systems, their speeds or phase positions are different, making it impossible to directly use the co-encapsulation, V1 fixed-position mode for carrying. As shown in Figure 25, the TU12 of channels 1, 2, and 3 are phase-aligned (appearing simultaneously in the V1 byte). The TU12 of channel 4 is not aligned with the first three channels. Therefore, it is necessary to move or regenerate the V1, V2, V3, and V4 positions of the TU12 of channel 4. The new V1 byte of channel 4 will then be aligned with the V1 position of the first three channels (when regenerating the V1 byte, the V2, V3, and V4 bytes will also be regenerated, so after the V1 byte is aligned, the positions of the V2, V3, and V4 bytes will naturally be aligned in sequence). Among the four bytes V1, V2, V3, and V4, V1V2 is a pointer value, indicating the position of the V5 byte in VC12 from V2. In Figure 25, before alignment, the V1V2 pointer value of channel 4 TU12 is 1 (V5 is the first byte position after V2), and after alignment, the V1V2 pointer value is 3 (V5 is the third byte position after V2). Byte V3 functions as an adjustment area, potentially carrying VC12 bytes or not. Byte V4 functions as a fixed padding area, providing a fixed padding value and not carrying VC12 content. Within a bearer frame, when the content of multiple TU12 streams is misaligned, the byte content of the multiple TU12 streams can be aligned by shifting or regenerating the positions of bytes V1, V2, V3, and V4. After alignment, multiple TU12 services can be carried using co-encapsulation and a fixed-position V1 mode.

[0122] In applications, after customer services are mapped to bearer frames with a length of 19 code blocks, an appropriate number of IDLE code blocks can be inserted between the bearer frames (for example, one IDLE code block can be inserted between every two bearer frames, or between every three bearer frames, or between every four bearer frames, etc.). After inserting the IDLE blocks, they can be mapped to sub-slots for transmission.

[0123] It should be noted that in practical applications, when the bearer frame carries TU12 services, in addition to the 19-code block length mentioned above, other lengths can also be used. The following will illustrate several possible implementation methods.

[0124] In some implementations, when a bearer frame is used to carry one TU12 service, the bearer frame may consist of one S-block, 72 D-blocks, and one T-block. The overhead region is located in the D-blocks, and the bearer region is located in the D-blocks and T-blocks. The bearer region includes a fixed bearer region of 576 bytes or includes a 1-byte adjustment region and a fixed bearer region of 575 bytes. Alternatively, one D-block can be reduced, and the overhead region can be located in the S-block. That is, a bearer frame may consist of one S-block, 71 D-blocks, and one T-block, with the overhead region located in the S-blocks, and the bearer region located in the S-blocks, D-blocks, and T-blocks. The bearer region includes a fixed bearer region of 576 bytes or includes a 1-byte adjustment region and a fixed bearer region of 575 bytes.

[0125] Taking the bearer frames shown in Figures 26 to 29 as an example, the bearer frame shown in Figure 26 consists of one S-block, 72 D-blocks, and one T-block. The overhead area (OH) is located in the D-block and has 5 overhead bytes. The bearer area is located in the D-block and T-block, and includes a 2-byte stuffing area (STF) and a 576-byte fixed bearer area. The V1 byte is carried at a fixed position in the bearer area, as shown in Figure 26, where the V1 byte is located at the last byte position of the first D-block (each bearer frame has 4 TU12s; the V1 byte of the first TU12 is located at the last byte position in the D-block, and the V1 bytes of the other TU12s are spaced 144 bytes apart). The bearer frame shown in Figure 26 can adopt the above-described independent encapsulation mode.

[0126] The bearer frame shown in Figure 26 can have one less D-block, and the overhead area can be placed in the S-block, as shown in Figure 27. The bearer frame shown in Figure 27 has one less D-block compared to the bearer frame shown in Figure 26, consisting of one S-block, 71 D-blocks, and one T-block. The overhead area (OH) of the bearer frame is located in the S-block and has 5 overhead bytes. The bearer area is located in the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF) and a 576-byte fixed bearer area. The V1 byte is carried at a fixed position in the bearer area, as shown in Figure 27, where the V1 byte is located at the last byte position in the S-block (each bearer frame has 4 TU12s; the V1 byte of the first TU12 is at the last byte position in the D-block, and the V1 bytes of the other TU12s are spaced 144 bytes apart). The bearer frame shown in Figure 27 can use the aforementioned independent encapsulation mode.

[0127] The bearer frame shown in Figure 28 consists of one S-block, 72 D-blocks, and one T-block. The overhead (OH) of the bearer frame is located in the D-block and has 5 overhead bytes. The bearer area is located in both the D-block and T-block, and includes a 1-byte stuffing area (STF), a 1-byte adjustment area (NJO), and a 575-byte fixed bearer area. The position of the V1 byte in the bearer area is not fixed; that is, the V1 byte is carried in a dynamically changing position within the bearer area. The position of the V1 byte may be different in each frame, requiring a specific byte position value to indicate its accurate position (each bearer frame has 4 TU12s; the specific byte position value indicates the position of the V1 byte in the first TU12, and the V1 bytes in the other TU12s are spaced 144 bytes apart). The bearer frame shown in Figure 28 can use an independent encapsulation mode.

[0128] The bearer frame shown in Figure 28 can have one less D-block, and the overhead area can be placed in the S-block, as shown in Figure 29. The bearer frame shown in Figure 29 has one less D-block compared to the bearer frame shown in Figure 28, consisting of one S-block, 71 D-blocks, and one T-block. The overhead area (OH) of the bearer frame is located in the D-block and has 5 overhead bytes. The bearer area is located in the D-block and T-block, and includes a 1-byte stuffing area (STF), a 1-byte adjustment area (NJO), and a 575-byte fixed bearer area. The position of the V1 byte in the bearer area is not fixed; that is, the V1 byte is carried in a dynamically changing position within the bearer area. The position of the V1 byte may be different in each frame, requiring a specific byte position value to indicate the accurate position of the V1 byte (each bearer frame has 4 TU12s; the specific byte position value indicates the position of the V1 byte in the first TU12, and the V1 bytes of the other TU12s are spaced 144 bytes apart). The bearer frame shown in Figure 29 can use an independent encapsulation mode.

[0129] In some implementations, when a bearer frame is used to carry four TU12 services, the bearer frame may consist of one S-block, 72 D-blocks, and one T-block. The overhead area is located in the D-block, and the bearer area is located in the D-block and T-block. The bearer area is divided into four groups, each including a 144-byte fixed bearer area or a 1-byte adjustment area and a 143-byte fixed bearer area. Alternatively, one D-block can be reduced, and the overhead area can be placed in the S-block. That is, a bearer frame consists of one S-block, 71 D-blocks, and one T-block, with the overhead area located in the S-block, and the bearer area located in the S-block, D-block, and T-block. The bearer area is divided into four groups, each including a 144-byte fixed bearer area or a 1-byte adjustment area and a 143-byte fixed bearer area.

[0130] Taking the bearer frames shown in Figures 30 to 33 as an example. The bearer frame shown in Figure 30 consists of one S-block, 72 D-blocks, and one T-block. The overhead (OH) of the bearer frame is located in the D-block and has 5 overhead bytes. The bearer area is located in the D-block and the T-block, and includes a 2-byte stuffing area (STF) and a 576-byte fixed bearer area. The 576-byte fixed bearer area is divided into 4 groups (each group is numbered by subscripts: group 1, group 2, group 3, group 4), with each group having 144 bytes of fixed bearer area. Each group carries 144 bytes from one TU12 channel. The V1 byte is carried at a fixed position in each group, as shown in the first position of each group in Figure 30. The bearer frame shown in Figure 30 can adopt the co-encapsulation mode described above.

[0131] The bearer frame shown in Figure 30 can have one less D-block, and the overhead area can be placed in the S-block, as shown in Figure 31. The bearer frame shown in Figure 31 has one less D-block compared to the bearer frame shown in Figure 30, consisting of one S-block, 71 D-blocks, and one T-block. The overhead area (OH) of the bearer frame is located in the S-block, with 5 overhead bytes. The bearer area is located in the S-block, D-block, and T-block, including a 1-byte stuffing area (STF) and a 576-byte fixed bearer area. The 576-byte fixed bearer area is divided into 4 groups (each group is numbered by subscripts: group 1, group 2, group 3, group 4), each group containing 144 bytes, carrying one TU12 channel of 144 bytes. The V1 byte is carried at a fixed position in each group, as shown in Figure 31, at the first position in each group. The bearer frame shown in Figure 31 can use the aforementioned co-encapsulation mode.

[0132] The bearer frame shown in Figure 32 consists of one S-block, 72 D-blocks, and one T-block. The overhead (OH) of the bearer frame is located in the D-block and has 5 overhead bytes. The bearer area is located in the D-block and T-block, and includes a 2-byte stuffing area (STF), a 4-byte adjustment area (NJO), and a 572-byte fixed bearer area. The 4-byte adjustment area (NJO) and the 572-byte fixed bearer area are divided into four groups, each group numbered by a subscript: Group 1, Group 2, Group 3, and Group 4. Each group contains one adjustment area and 143 bytes, carrying 144 bytes from one TU12 channel. The position of the V1 byte within each group is not fixed; it is carried in a dynamically changing position within each group. A specific byte position value is needed to indicate the exact position of the V1 byte in each TU12 channel. The bearer frame shown in Figure 32 can adopt the co-encapsulation mode described above.

[0133] The bearer frame shown in Figure 32 can have one less D-block, and the overhead area can be placed in the S-block, as shown in Figure 33. The bearer frame shown in Figure 33 has one less D-block compared to the bearer frame shown in Figure 32, consisting of one S-block, 71 D-blocks, and one T-block. The overhead area (OH) of the bearer frame is located in the S-block and has 5 overhead bytes. The bearer area is located in the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF), a 4-byte adjustment area (NJO), and a 572-byte fixed bearer area. The 4-byte adjustment area (NJO) and the 572-byte fixed bearer area are divided into 4 groups, each group numbered by a subscript: Group 1, Group 2, Group 3, and Group 4. Each group has one adjustment area and 143 bytes, carrying 144 bytes in one TU12 channel. The position of the V1 byte in each group is not fixed; that is, it is carried in a dynamically changing position within each group. Therefore, a specific byte position value is needed to indicate the exact position of the V1 byte in each TU12 channel. The bearer frame shown in Figure 33 can adopt the co-encapsulation mode described above.

[0134] In some implementations, when a bearer frame is used to carry four TU12 services, the bearer frame may consist of one S-block, 44 D-blocks, and one T-block. The overhead area is located in the D-block, and the bearer area is located in the D-block and T-block. The bearer area is divided into four groups, each including an 88-byte fixed bearer area or a 1-byte adjustment area and an 87-byte fixed bearer area. Alternatively, one D-block can be reduced, and the overhead area can be placed in the S-block. That is, a bearer frame consists of one S-block, 43 D-blocks, and one T-block, with the overhead area located in the S-block, and the bearer area located in the S-block, D-block, and T-block. The bearer area is divided into four groups, each including an 88-byte fixed bearer area or a 1-byte adjustment area and an 87-byte fixed bearer area.

[0135] Taking the bearer frames shown in Figures 34 and 35 as examples, the bearer frame shown in Figure 34 consists of one S-block, 44 D-blocks, and one T-block. The overhead (OH) of the bearer frame is located in the D-block and has 5 overhead bytes. The bearer area is located in the D-block and T-block, and includes a 2-byte stuffing area (STF) and a 352-byte fixed bearer area. The 352-byte fixed bearer area is divided into 4 groups (each group is indicated by a subscript: group number 1, group number 2, group number 3, group number 4). Each group includes a 1-byte adjustment area and an 87-byte fixed bearer area. Each group carries 88 bytes of one TU12 service. Different TU12 services can have independent clock frequencies. The position of the V1 byte in the bearer area is not fixed; that is, the V1 byte is carried in a dynamically changing position within the bearer area. The position of the V1 byte may be different in each frame, and a specific byte position value is needed to indicate the accurate position of the V1 byte. The bearer frame shown in Figure 34 can adopt the co-encapsulation mode described above.

[0136] The bearer frame shown in Figure 34 can have one less D-block, and the overhead area can be placed in the S-block, as shown in Figure 35. The bearer frame shown in Figure 35 has one less D-block compared to the bearer frame shown in Figure 34, consisting of one S-block, 43 D-blocks, and one T-block. The overhead area (OH) of the bearer frame is located in the S-block and has 5 overhead bytes. The bearer area is located in the S-block, D-block, and T-block, and includes a 1-byte stuffing area (STF) and a 352-byte fixed bearer area. The 352-byte fixed bearer area is divided into 4 groups (each group is numbered by subscripts: group 1, group 2, group 3, group 4). Each group includes a 1-byte adjustment area and an 87-byte fixed bearer area. Each group carries 88 bytes of one TU12 service. Different TU12 services can have independent clock frequencies. The position of byte V1 in the bearer area is not fixed; that is, byte V1 is carried in a dynamically changing position within the bearer area. The position of byte V1 may be different in each frame, and a specific byte position value is needed to indicate the accurate position of byte V1. The bearer frame shown in Figure 35 can adopt the co-encapsulation mode described above.

[0137] For the bearer frames used to carry TU12 services, after mapping customer services to the bearer frames, an appropriate number of IDLE code blocks can be inserted between the bearer frames (for example, inserting 1 IDLE code block between each bearer frame, or inserting 1 IDLE code block between each bearer frame, or inserting 4 IDLE code blocks between each bearer frame, or inserting 5 IDLE code blocks between each bearer frame, etc.). Inserting IDLE blocks allows them to be mapped to sub-time slots for transmission.

[0138] It should be noted that in some implementations, the TU12 service speed and the bearer frame speed are the same, and no adjustment of the adjustment area is required. However, the bearer area length of the bearer frame and the 144-byte length of the TU12 service are not integer multiples of each other. Thus, the position of the V1 byte in TU12 is different in each bearer frame, and a special byte position value is needed to indicate the specific position of the V1 byte in each bearer frame.

[0139] Figure 36 shows the VC12 service structure in the SDH standard. The VC12 service consists of four groups of bytes, each group containing 35 bytes, for a total of 140 bytes. The specific byte for the VC12 service is the V5 byte. Since the 140 bytes of the VC12 service can be combined with the addition of bytes V1, V2, V3, and V4 to form the TU12 service, the bearer frames described above for carrying the TU12 service can also be used to carry the VC12 service. For example, the bearer frames shown in Figures 15 and 16 can be used to carry the VC12 service; the difference is that the specific byte for the VC12 service is the V5 byte, not the V1 byte.

[0140] The VC12 service operates at a speed of 2.24 Mbps (bit / s), while the pipeline speed of a sub-slot in a fine-grained frame within the service layer is 10 Mbps (bit / s; in some scenarios, this may be higher, such as 10.1 Mbps). Therefore, a sub-slot in a fine-grained frame can carry a maximum of four VC12 services: one, two, three, or four. With one VC12 service per sub-slot, the required carrying efficiency is at least 1 * 2.24 / 10 = 22.4% (22.18% when the sub-slot speed is 10.1 Mbps). With two VC12 services per sub-slot, the required carrying efficiency is at least 2 * 2.24 / 10 = 44.8% (44.36% when the sub-slot speed is 10.1 Mbps). When a sub-time slot carries 3 VC12 services, the corresponding carrying efficiency needs to reach at least 3*2.24 / 10 = 67.2% (66.53% when the sub-time slot speed is calculated at 10.1M). When a sub-time slot carries 4 VC12 services, the corresponding carrying efficiency needs to reach at least 4*2.24 / 10 = 89.6% (88.71% when the sub-time slot speed is calculated at 10.1M).

[0141] When a bearer frame is used to carry one or more VC12 services, the encapsulation mode of the bearer frame can also include the independent encapsulation mode and the co-encapsulation mode described above. In independent encapsulation mode, each VC12 service is independently encapsulated in its own bearer frame; that is, one VC12 service from one customer is independently encapsulated in one bearer frame. In co-encapsulation mode, multiple VC12 services are encapsulated in one bearer frame, meaning all or part of the VC12 services from multiple customers are encapsulated in one bearer frame. Furthermore, in co-encapsulation mode, multiple VC12 services can share the S-block, T-block, and overhead area of ​​the bearer frame and have independent adjustment areas and fixed bearer areas. Optionally, the multiple VC12 services can also have independent adjustment indicators. Optionally, the multiple VC12 services can have the same or independent specific byte position values.

[0142] In independent encapsulation mode, when mapping multiple bearer frames carrying multiple VC12 services to a single sub-time slot for transmission, the multiple bearer frames can be interleaved and mapped to a single sub-time slot for transmission. There are two interleaving methods: one is to interleave the multiple bearer frames sequentially frame by frame before mapping them to a single sub-time slot; the other is to interleave the multiple bearer frames sequentially block by block before mapping them to a single sub-time slot. For details, please refer to the specific implementation method of interleaving TU12 bearer frames described above, which will not be repeated here.

[0143] The following will use some more specific implementation examples to illustrate the possible frame structure of a bearer frame when it carries one or more VC12 services.

[0144] In some implementations, when a bearer frame is used to carry one VC12 service, the bearer frame may consist of one S-block, 17 D-blocks, and one T-block. The overhead area is located in the S-block, and the bearer area is located in the S-block, D-block, and T-block. The bearer area includes a 140-byte fixed bearer area or includes a 1-byte adjustment area and a 139-byte fixed bearer area. The bearer frame can be in independent encapsulation mode. The V5 byte of the VC12 service can be carried at a fixed position in the bearer area, or at a dynamically changing position in the bearer area, with a specific byte position value indicating the exact position of the V5 byte in the bearer area.

[0145] In some implementations, when a bearer frame is used to carry four VC12 services, the bearer frame may consist of one S-block, 17 D-blocks, and one T-block. The overhead area of ​​the bearer frame may be located in the S-block, and the bearer area may be located in the S-block, D-block, and T-block. The bearer area is divided into four groups, each including a 35-byte fixed bearer area or including a 1-byte adjustment area and a 34-byte fixed bearer area. The bearer frame may be in co-encapsulation mode, where the V5 byte of each VC12 service may be carried at a fixed position in the bearer area, or at a dynamically changing position in the bearer area, with a specific byte position value indicating the exact position of the V5 byte in the bearer area.

[0146] In some implementations, when a bearer frame is used to carry one VC12 service, the bearer frame may consist of one S-block, 72 D-blocks, and one T-block. The overhead area is located in the D-blocks, and the bearer area is located in the D-blocks and T-blocks. The bearer area includes a fixed bearer area of ​​560 bytes or includes an adjustment area of ​​1 byte and a fixed bearer area of ​​559 bytes. Alternatively, one D-block can be reduced, and the overhead area can be set in the S-block. That is, a bearer frame may consist of one S-block, 71 D-blocks, and one T-block, with the overhead area located in the S-blocks, and the bearer area located in the S-blocks, D-blocks, and T-blocks. The bearer area includes a fixed bearer area of ​​560 bytes or includes an adjustment area of ​​1 byte and a fixed bearer area of ​​559 bytes. The bearer frame can be in independent encapsulation mode. The V5 byte of the VC12 service can be carried at a fixed position in the bearer area or at a dynamically changing position in the bearer area, and the exact position of the V5 byte in the bearer area can be indicated by a specific byte position value.

[0147] In some implementations, when a bearer frame is used to carry four VC12 services, the bearer frame may consist of one S-block, 72 D-blocks, and one T-block. The overhead region is located in the D-block, and the bearer region is located in the D-block and T-block. The bearer region is divided into four groups, each including a 140-byte fixed bearer region or a 1-byte adjustment region and a 139-byte fixed bearer region. Alternatively, one D-block can be reduced, and the overhead region is placed in the S-block. That is, a bearer frame consists of one S-block, 71 D-blocks, and one T-block, with the overhead region located in the S-block, and the bearer region located in the S-block, D-block, and T-block. The bearer region is divided into four groups, each including a 140-byte fixed bearer region or a 1-byte adjustment region and a 139-byte fixed bearer region. The bearer frame can be in co-encapsulation mode, where the V5 byte of each VC12 service can be carried at a fixed position in the bearer area, or at a dynamically changing position in the bearer area, and the exact position of the V5 byte in the bearer area can be indicated by a specific byte position value.

[0148] In some implementations, when a bearer frame is used to carry four VC12 services, the bearer frame may consist of one S-block, 44 D-blocks, and one T-block. The overhead region is located in the D-blocks, and the bearer region is located in the D-blocks and T-blocks. The bearer region is divided into four groups, each including an 88-byte fixed bearer region or a 1-byte adjustment region and an 87-byte fixed bearer region. Alternatively, one D-block can be reduced, and the overhead region can be located in the S-block. That is, a bearer frame consists of one S-block, 43 D-blocks, and one T-block, with the overhead region located in the S-blocks, and the bearer region located in the S-blocks, D-blocks, and T-blocks. The bearer region is divided into four groups, each including an 88-byte fixed bearer region or a 1-byte adjustment region and an 87-byte fixed bearer region. The bearer frame can be in co-encapsulation mode, where the V5 byte of each VC12 service can be carried at a fixed position in the bearer area, or at a dynamically changing position in the bearer area, and the exact position of the V5 byte in the bearer area can be indicated by a specific byte position value.

[0149] It should be noted that the bearer frames shown in Figures 21 to 24 and 26 to 35, which are used to carry TU12 services, can also be used to carry VC12 services. The difference is that the specific bytes in these bearer frames are V5 bytes, not V1 bytes. Furthermore, since VC12 services are 4 bytes shorter than TU12 services, the bearer areas shown in Figures 21 to 24 and 26 to 35 will have a 4-byte gap. In this case, these 4 bytes can carry fixed padding content, overhead information, or other bytes; no specific limitations are made here.

[0150] For bearer frames used to carry VC12 services, after mapping customer services to VC12 bearer frames, an appropriate number of IDLE code blocks can be inserted between bearer frames (e.g., 1 IDLE code block between each bearer frame, or 4 IDLE code blocks between each bearer frame, or 5 IDLE code blocks between each bearer frame, etc.). Inserting IDLE blocks allows them to be mapped to sub-time slots for transmission.

[0151] Figure 37 shows the AU4 service structure in the SDH standard. The AU4 service includes H1 bytes + padding bytes + padding bytes + H2 bytes + padding bytes + padding bytes + H3 bytes + H3 bytes + H3 bytes + 2349 (9*261) bytes, totaling 2358 bytes. When carrying AU services, the entire 2358 bytes can be transmitted, or the fixed padding content (i.e., padding bytes) can be omitted, and only 2358-4=2354 bytes can be transmitted, which is the simplified structure shown in Figure 38.

[0152] The bearer frame provided in this application embodiment can be used to carry AU4 services. When carrying AU4 services, one bearer frame can carry one AU4 service. When mapping a bearer frame carrying one AU4 service to a sub-time slot of the service layer, one bearer frame can be mapped to 15 or 16 sub-time slots.

[0153] In some implementations, when a bearer frame is used to carry one AU4 service, the bearer frame may consist of one S-block, 120 D-blocks, and one T-block. The overhead region is located in the D-blocks, and the bearer region is located in the D-blocks and T-blocks. The bearer region includes a fixed bearer region of 962 bytes or includes a 1-byte adjustment region and a fixed bearer region of 961 bytes. Alternatively, one D-block can be reduced, and the overhead region is set in the S-block. That is, a bearer frame consists of one S-block, 119 D-blocks, and one T-block. The overhead region is located in the S-blocks, and the bearer region is located in the S-blocks, D-blocks, and T-blocks. The bearer region includes a fixed bearer region of 962 bytes or includes a 1-byte adjustment region and a fixed bearer region of 961 bytes.

[0154] Take the bearer frame shown in Figures 39 and 40 as an example. The bearer frame shown in Figure 39 consists of one S-block, 120 D-blocks, and one T-block. The overhead (OH) of the bearer frame is located in the D-block and has 5 overhead bytes. The bearer area is located in the D-block and T-block, and includes a 1-byte adjustment area (NJO) and a 961-byte fixed bearer area. The position of the H1 byte in the bearer area is not fixed; that is, the H1 byte is carried in a dynamically changing position within the bearer area. The position of the H1 byte may be different in each frame, and a specific byte position value is needed to indicate the accurate position of the H1 byte. The bearer frame shown in Figure 39 can adopt the above-described independent encapsulation mode.

[0155] The bearer frame shown in Figure 39 can have one less D-block, and the overhead area can be placed in the S-block, as shown in Figure 40. The bearer frame shown in Figure 40 has one less D-block compared to the bearer frame shown in Figure 39, consisting of one S-block, 119 D-blocks, and one T-block. The overhead area (OH) of the bearer frame is located in the S-block and has four overhead bytes. The bearer area is located in the S-block, D-block, and T-block, and includes a one-byte adjustment area (NJO) and a 961-byte fixed bearer area. The position of the H1 byte in the bearer area is not fixed; that is, the H1 byte is carried in a dynamically changing position within the bearer area. The position of the H1 byte may be different in each frame, requiring a specific byte position value to indicate the accurate position of the H1 byte. The bearer frame shown in Figure 40 can adopt the aforementioned independent encapsulation mode.

[0156] For bearer frames used to carry AU4 services, after mapping customer services to bearer frames, an appropriate number of IDLE code blocks can be inserted between bearer frames (e.g., 1 IDLE code block between each bearer frame, or 4 IDLE code blocks between each bearer frame, or 5 IDLE code blocks between each bearer frame, etc.). Inserting IDLE blocks allows them to be mapped to sub-time slots for transmission.

[0157] Figure 41 shows the VC4 service structure in the SDH standard. The VC4 service consists of 2349 (9*261) bytes. The VC4 service is formed by removing the H1, H2, H3 bytes and padding bytes from the 2358 bytes of the AU4 service (for the simplified AU4 service, removing the H1, H2, and H3 bytes results in the VC4 service). In this embodiment, the bearer frame used to carry the AU4 service can also be used to carry the VC4 service; the difference is that the specific byte is the J1 byte, not the H1 byte.

[0158] When a bearer frame is used to carry VC4 services, one bearer frame can carry one VC4 service. When mapping a bearer frame carrying one VC4 service to sub-time slots in the service layer, one bearer frame can be mapped to 15 or 16 sub-time slots.

[0159] In some implementations, when a bearer frame is used to carry one VC4 service, the bearer frame may consist of one S-block, 120 D-blocks, and one T-block. The overhead region is located in the D-blocks, and the bearer region is located in the D-blocks and T-blocks. The bearer region includes a fixed bearer region of 962 bytes or includes a 1-byte adjustment region and a fixed bearer region of 961 bytes. Alternatively, one D-block can be reduced, and the overhead region can be set in the S-block. That is, a bearer frame consists of one S-block, 119 D-blocks, and one T-block. The overhead region is located in the S-blocks, and the bearer region is located in the S-blocks, D-blocks, and T-blocks. The bearer region includes a fixed bearer region of 962 bytes or includes a 1-byte adjustment region and a fixed bearer region of 961 bytes.

[0160] Take the bearer frames shown in Figures 39 and 40 as an example. The bearer frames shown in Figures 39 and 40 can also be used to carry VC4 services, the difference being that the specific byte is the J1 byte, not the H1 byte.

[0161] For bearer frames used to carry VC4 services, after mapping customer services to bearer frames, an appropriate number of IDLE code blocks can be inserted between bearer frames (e.g., 1 IDLE code block between each bearer frame, or 4 IDLE code blocks between each bearer frame, or 5 IDLE code blocks between each bearer frame, etc.). Inserting IDLE blocks allows them to be mapped to sub-time slots for transmission.

[0162] It should be noted that, in addition to carrying TU12, VC12, AU4 and VC4 services, the bearer frames provided in this application embodiment can also carry services defined in the SDH system standards such as TU11, TU2, TU3 and AU3, which will not be described in detail here.

[0163] The bearer frame provided in this application embodiment consists of S-blocks, D-blocks, and T-blocks. The bearer frame includes an overhead area and a bearer area. The overhead area carries overhead information, and the bearer area carries the first client content. Idle blocks are inserted between multiple bearer frames before being mapped to sub-time slots in the service layer for transmission. One bearer frame carries one or more first services. Thus, when carrying services in the SDH architecture standard (such as TU12, VC12, AU4, or VC4 services) in sub-time slots based on the FlexE protocol standard, one or more services to be carried can be mapped to a bearer frame. Then, idle blocks are inserted between multiple bearer frames before being mapped to sub-time slots for transmission. This enables the carrying of services in the SDH architecture standard, meeting the service carrying requirements.

[0164] Based on the bearer frame provided in the embodiments of this application, when carrying the first service, the carrying method for the sending end can be as shown in Figure 42.

[0165] Figure 42 is a schematic flowchart of a bearer method according to an embodiment of this application. The bearer method shown in Figure 42 can be executed by the sending end and may specifically include the following steps.

[0166] S422: Map the first service to be carried to the bearer frame.

[0167] The bearer frame here is the bearer frame provided in the embodiments of this application. The specific structure of the bearer frame can be found in the embodiments shown in Figures 6 to 41 above, and will not be described in detail here.

[0168] The first service is the service in the SDH system standard. Specifically, it can be TU12 service, VC12 service, AU4 service, or VC4 service.

[0169] When carrying the first service, the sending end can map the first service to be carried into a bearer frame. Specifically, the first service of one customer (i.e., one first service) can be mapped into one bearer frame, corresponding to the independent encapsulation mode. Alternatively, all or part of the first services of multiple customers (i.e., multiple first services) can be mapped into one bearer frame, corresponding to the co-encapsulation mode.

[0170] S424: Map the bearer frame to a sub-slot.

[0171] When mapping bearer frames to sub-time slots, one or more bearer frames can be mapped to one sub-time slot, or one bearer frame can be mapped to multiple sub-time slots. In some implementations, when the first service is a TU12 service or a VC12 service, one bearer frame can be mapped to one sub-time slot, or multiple bearer frames can be mapped to one sub-time slot. Specifically, when one bearer frame is mapped to one sub-time slot, one bearer frame is used to carry multiple TU12 or VC12 services; when multiple bearer frames are mapped to one sub-time slot, each bearer frame is used to carry one TU12 or VC12 service, or to carry a portion of multiple TU12 or VC12 services. In other implementations, when the first service is an AU4 service or a VC4 service, one bearer frame can be mapped to 15 or 16 sub-time slots.

[0172] When mapping multiple bearer frames into a sub-time slot, if these multiple bearer frames are used to carry multiple first services, then when mapping to a sub-time slot, these multiple bearer frames (which can also be represented as multiple bearer frames) can be sequentially interleaved and mapped to a sub-time slot in units of frames, or sequentially interleaved and mapped to a sub-time slot in units of code blocks, so that the transmission delay time of the first service for each customer is equal. Furthermore, to further reduce the encapsulation delay time of the first service, multiple such bearer frames can also be sequentially interleaved and mapped to a sub-time slot in units of code blocks. For example, if the first service is a TU12 service, when mapping four bearer frames carrying four TU12 services to a sub-time slot, they can be sequentially interleaved and mapped to a sub-time slot in units of frames, as shown in the embodiment of Figure 17, or sequentially interleaved and mapped to a sub-time slot in units of code blocks, as shown in the embodiment of Figure 18.

[0173] Optionally, when mapping bearer frames to sub-slots, idle code blocks can be inserted between bearer frames so that intermediate devices in the network can adapt the block rate speed to the speed of the device clock by adding or deleting idle code blocks. The number of idle code blocks inserted can be one or more, without specific limitation, as long as the bearer frame's carrying efficiency requirements are met.

[0174] In addition to inserting idle code blocks between bearer frames, OAM code blocks (abbreviated as O blocks or O blocks) can also be inserted between bearer frames as needed. OAM code blocks can be used to monitor the service quality of the service layer during the transmission of bearer frames, such as latency and bit error rate. When OAM monitoring is required, an appropriate number of OAM code blocks can be inserted between bearer frames.

[0175] S426: Send sub-time slots to the receiver.

[0176] After mapping the bearer frame to the sub-time slot, the sub-time slot can be sent to the receiving end, thereby enabling the bearing and transmission of the first service.

[0177] Based on the bearer frame provided in the embodiments of this application, when the sending end carries the first service based on the bearer frame, the carrying method for the receiving end can be as shown in Figure 43.

[0178] Figure 43 is a schematic flowchart of a bearer method according to an embodiment of this application. The bearer method shown in Figure 43 can be executed by the receiving end and may specifically include the following steps.

[0179] S432: Sub-time slot sent by the receiving end.

[0180] When the transmitting end maps the bearer frame to a sub-time slot and sends the sub-time slot to the receiving end based on the method described in the embodiment shown in FIG42, the receiving end can receive the sub-time slot.

[0181] S434: Analyze the sub-time slots and extract the bearer frames from the sub-time slots.

[0182] When mapping a bearer frame to a sub-time slot, the transmitting end can use various mapping methods. When parsing a sub-time slot, the receiving end can perform corresponding demapping based on the mapping method to extract the bearer frame from the sub-time slot. In practical applications, the transmitting and receiving ends can pre-agree (or be specified by the protocol) on which mapping method to use. Thus, when the transmitting end maps a bearer frame to a sub-time slot, it can use the agreed-upon (or protocol-specified) mapping method, and the receiving end can use the corresponding method for demapping. These mapping methods may include, but are not limited to: mapping one bearer frame to one sub-time slot; mapping multiple bearer frames to one sub-time slot without interleaving; and sequentially interleaving multiple bearer frames (each bearer frame carrying the first service of one customer, or multiple bearer frames carrying the first services of multiple customers) (interleaving sequentially in frames or code blocks) before mapping them to one sub-time slot.

[0183] When the transmitting end interleaves multiple bearer frames and maps them to a sub-time slot, the receiving end, when parsing the sub-time slot and extracting the bearer frames from it, may include:

[0184] The bearer frames are extracted according to the interleaving order on a frame-by-frame basis to obtain multiple bearer frames; or,

[0185] The code blocks are extracted in an interleaved order based on code blocks. The S code blocks, D code blocks and T code blocks corresponding to the first service of the same path are merged to obtain a multi-path bearer frame.

[0186] For example, when the first service is TU12 or VC12, the transmitting end can map the four bearer frames into a sub-time slot by interleaving them sequentially in units of frames, as shown in Figure 17. The receiving end can then extract the bearer frames according to the interleaving order in units of frames when parsing the sub-time slot, resulting in four bearer frames, as shown in Figure 19. Alternatively, if the transmitting end maps the four bearer frames into a sub-time slot by interleaving them sequentially in units of code blocks, as shown in Figure 18, the receiving end can extract the code blocks according to the interleaving order in units of code blocks when parsing the sub-time slot. Then, it can merge the S, D, and T code blocks corresponding to the same TU12 or VC12 service, thus obtaining four bearer frames, as shown in Figure 20.

[0187] In some implementations, when the transmitter maps the bearer frame to the sub-slot, it can insert idle code blocks and / or OAM code blocks between the bearer frames. Then, when the receiver parses the sub-slot, it can first strip the OAM code blocks and idle code blocks, and then extract the bearer frame.

[0188] S436: Parse the S-code block, D-code block and T-code block in the bearer frame to extract the customer content of the TU12 service carried by the bearer frame.

[0189] After extracting the bearer frame from the sub-time slot, the receiving end can first parse the S-code block and D-code block in the bearer frame to obtain the overhead field in the overhead area of ​​the bearer frame. Based on the indication in the overhead field, it can determine the byte positions carrying the client content in the D-code block and T-code block, and then extract the client content carried in these byte positions. After parsing the T-code block, the client content carried in the bearer frame can be extracted.

[0190] Based on the bearer frame provided in the embodiments of this application, when carrying services in the SDH system standard in the sub-time slots of the FlexE protocol standard, one or more services to be carried can be mapped to the bearer frame, and then the bearer frame can be mapped to the sub-time slots for transmission. Thus, the services in the SDH system standard can be carried, and the service carrying requirements can be met.

[0191] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0192] Figure 44 is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Referring to Figure 44, at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include RAM, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk storage device. Of course, the electronic device may also include other hardware required for other services.

[0193] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be categorized as an address bus, data bus, control bus, etc. For ease of illustration, only a single bidirectional arrow is used in Figure 44, but this does not imply that there is only one bus or one type of bus.

[0194] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0195] The processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming a bearer device at the logical level. The processor executes the program stored in memory and specifically performs the following operations: mapping the first service to be carried to a bearer frame; mapping the bearer frame to a sub-time slot; and transmitting the sub-time slot to the receiving end.

[0196] Alternatively, it can be used to perform the following operations: receive a sub-time slot sent by the sending end; parse the sub-time slot and extract the bearer frame in the sub-time slot; parse the S-code block, D-code block and T-code block in the bearer frame and extract the client content of the first service carried by the bearer frame.

[0197] The method executed by the carrier device as disclosed in the embodiment shown in Figure 44 of this application can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0198] The electronic device can also perform the methods of FIG42 and FIG43 and realize the functions of the carrier device in the embodiments shown in FIG42 and FIG43, which will not be described in detail here.

[0199] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0200] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform the methods of the embodiments shown in Figures 42 and 43, and specifically to perform the following operations: mapping a first service to be carried to a bearer frame; mapping the bearer frame to a sub-time slot; and transmitting the sub-time slot to a receiving end.

[0201] Alternatively, it can be used to perform the following operations: receive a sub-time slot sent by the sending end; parse the sub-time slot and extract the bearer frame in the sub-time slot; parse the S-code block, D-code block and T-code block in the bearer frame and extract the client content of the first service carried by the bearer frame.

[0202] Figure 45 is a schematic diagram of the structure of a bearer device 450 according to an embodiment of this application. Referring to Figure 45, in one software implementation, the bearer device 450 may include: a first mapping module 451, a second mapping module 452, and a sending module 453, wherein: the first mapping module 451 maps the first service to be carried to a bearer frame; the second mapping module 452 maps the bearer frame to a sub-time slot; and the sending module 453 sends the sub-time slot to the receiving end.

[0203] In some embodiments, the second mapping module 452 maps the bearer frame to a sub-time slot, including: mapping one or more of the bearer frames to one sub-time slot; wherein, when one bearer frame is mapped to one sub-time slot, one bearer frame is used to carry multiple first services, and when multiple bearer frames are mapped to one sub-time slot, each bearer frame is used to carry one first service or a portion of the services in multiple first services.

[0204] In some embodiments, the second mapping module 452 maps multiple bearer frames into one sub-time slot, including: sequentially interleaving multiple bearer frames in units of frames and then mapping them into one sub-time slot; or, sequentially interleaving multiple bearer frames in units of code blocks and then mapping them into one sub-time slot.

[0205] In some implementations, the second mapping module 452 maps a plurality of the bearer frames to a single sub-slot, including:

[0206] In the case where one of the bearer frames is used to carry one AU4 service or VC4 service, one of the bearer frames is mapped to 15 or 16 of the sub-time slots.

[0207] The carrier device 450 provided in this application can also perform the method of FIG42 and realize the function of the carrier device 450 in the embodiment shown in FIG42, which will not be described again here.

[0208] Figure 46 is a schematic diagram of the structure of a bearer device 460 according to an embodiment of this application. Referring to Figure 46, in one software implementation, the bearer device 460 may include: a receiving module 461, a first parsing module 462, and a second parsing module 463, wherein: the receiving module 461 receives a sub-time slot transmitted by the transmitting end; the first parsing module 462 parses the sub-time slot to extract the bearer frame in the sub-time slot; and the second parsing module 463 parses the S-code block, D-code block, and T-code block in the bearer frame to extract the client content of the first service carried by the bearer frame.

[0209] In some implementations, the first parsing module 462 parses the sub-time slot and extracts the bearer frames in the sub-time slot, including: extracting the bearer frames according to the interleaving order in units of frames to obtain multiple bearer frames; or, extracting the code blocks according to the interleaving order in units of code blocks, merging the S code blocks, D code blocks and T code blocks corresponding to the same first service to obtain multiple bearer frames.

[0210] The carrier device 460 provided in this application can also perform the method of FIG43 and realize the function of the carrier device 460 in the embodiment shown in FIG43, which will not be described again here.

[0211] This application also proposes a computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the above-described carrier method embodiments.

[0212] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

[0213] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0214] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0215] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0216] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A bearer frame, comprising S-blocks, D-blocks, and T-blocks, including an overhead region and a bearer region, wherein: The overhead area is used to carry overhead information; The carrying area is used to carry the customer content of the first service; After interpolating idle code blocks between multiple bearer frames, they are mapped to sub-slots of the service layer for transmission. One bearer frame is used to carry one or more of the first services.

2. The bearer frame as described in claim 1, wherein the first service is a TU12 service, or a VC12 service, or an AU4 service, or a VC4 service; in, When the first service is a TU12 or VC12 service, one bearer frame is used to carry one or more of the first service; when the first service is an AU4 or VC4 service, one bearer frame is used to carry one of the first service.

3. The bearer frame as claimed in claim 1, wherein the overhead information includes at least one of the following: SDH frame overhead content is used to carry the overhead of the regenerator section layer and the multiplex section layer. Multiframe indicator, used to indicate the sequential relationship of multiple carrier frames in a multiframe group; Service type, used to characterize the type of service carried by the bearer frame; Customer ID, used to distinguish different bearer frames carrying different customer services; An adjustment indicator is used to indicate whether the adjustment area of ​​the carrying area carries customer content. Cyclic redundancy check.

4. The bearer frame as claimed in claim 1, wherein the bearer area comprises at least one of the following: The fixed insertion area is used to hold fixed fill content and does not hold customer content. The adjustment area is used to hold fixed fill content or customer content. Fixed hosting area, used to host customer content.

5. The bearer frame as described in claim 1, wherein the bearer frame further includes a specific byte position value; in, The specific byte position value is located in the overhead area, or after the overhead area and before the bearer area, or at the beginning of the bearer area.

6. The bearer frame as claimed in claim 5, wherein, if the specific byte position value is within the valid range of the bearer frame, the specific byte position value is used to indicate the position of the specific byte of the first service in the bearer area.

7. The bearer frame as described in claim 5, wherein if the specific byte position value is not within the valid range of the bearer frame, the specific byte position value is used to indicate that there is no specific byte carrying the first service in the bearer frame, or to indicate that there is no customer service in the bearer frame, or to indicate that the customer service is faulty.

8. The bearer frame as described in claim 6, wherein a specific byte of the first service is carried at a fixed position or a dynamically changing position in the bearer area, and the specific byte position value is used to indicate the position of the specific byte of the first service in the bearer area.

9. The bearer frame as claimed in claim 8, wherein when the bearer frame is used to carry one of the first services, the specific byte position value includes a set of specific byte position values, the set of specific byte position values ​​being used to indicate the position of a specific byte of the first service in the bearer area; When the bearer frame is used to carry multiple paths of the first service, the specific byte position value includes a set of specific byte position values. The set of specific byte position values ​​is used to indicate the position of a specific byte of a different path of the first service in the bearer area at different times through time division multiplexing. Alternatively, the specific byte position value includes multiple sets of specific byte position values, and each set of specific byte position values ​​is used to indicate the position of a specific byte of one path of the first service in the bearer area.

10. The bearer frame as described in any one of claims 5 to 9, wherein when the first service is a TU12 service, a specific byte of the first service is a V1 byte; When the first service is a VC12 service, the specific byte of the first service is the V5 byte; When the first service is an AU4 service, the specific byte of the first service is the H1 byte; When the first service is a VC4 service, the specific byte of the first service is byte J1.

11. The bearer frame as described in any one of claims 5 to 9, wherein the specific byte position value is a numerical value of multiple bits, or a pointer value of 1 byte, or a pointer value of 2 bytes.

12. The bearer frame as described in claim 11, wherein when the specific byte position value is a pointer value of 1 byte, the pointer value of the 1 byte is a V byte or an H byte; When the pointer value at the specified byte position is a 2-byte pointer value, the 2-byte pointer value is either V1 byte and V2 byte, or H1 byte and H2 byte.

13. The bearer frame as claimed in claim 1, wherein when the first service is a TU12 service or a VC12 service and one bearer frame is used to carry multiple first services, the multiple first services share the S code block, T code block and overhead area in the bearer frame and have independent adjustment area and fixed bearer area.

14. The bearer frame as described in claim 13, wherein multiple first services further have independent adjustment instructions.

15. The bearer frame as claimed in claim 1, wherein when the first service is a TU12 service or a VC12 service, one bearer frame is used to carry one first service and multiple first services are carried in different bearer frames, the multiple bearer frames used to carry multiple first services are mapped to one sub-time slot; in, When mapping the multiple bearer frames to a sub-time slot, the multiple bearer frames are sequentially interleaved in units of frames and then mapped to a sub-time slot, or sequentially interleaved in units of code blocks and then mapped to a sub-time slot.

16. The bearer frame as described in claim 1, where the first service is a TU12 service, and one bearer frame carries multiple TU12 services and the V1 byte of each TU12 service is carried at a fixed position in the bearer area, if the arrival times of the V1 bytes of different TU12 services are not synchronized, the positions of the V1 bytes of multiple TU12 services are aligned by regenerating the V1 bytes in the TU12 services.

17. The bearer frame as described in claim 16, wherein in the case of regenerating the V1 byte in the TU12 service, the V2, V3, and V4 bytes in the TU12 service are regenerated following the V1 byte.

18. The bearer frame as claimed in claim 1, wherein when the first service is an AU4 service or a VC4 service, and one bearer frame is used to carry one AU4 service or one VC4 service, one bearer frame is used to map to 15 or 16 of the sub-time slots.

19. The bearer frame according to any one of claims 1 to 9, 13 to 17, wherein the first service is a TU12 service or a VC12 service and one of the bearer frames is used to carry one channel of the first service: A bearer frame consists of one S-block, 17 D-blocks, and one T-block. The overhead region is located in the S-block, and the bearer region is located in the S-block, D-block, and T-block. The bearer region includes a fixed bearer region of 144 bytes, or a fixed bearer region of 143 bytes including an adjustment region, or a fixed bearer region of 140 bytes, or a fixed bearer region of 139 bytes including an adjustment region.

20. The bearer frame according to any one of claims 1 to 9, 13 to 17, wherein the first service is a TU12 service or a VC12 service and one bearer frame is used to carry four channels of the first service: A bearer frame consists of one S-block, 17 D-blocks, and one T-block. The overhead area is located in the S-block, and the bearer area is located in the S-block, D-block, and T-block. The bearer area is divided into four groups, each group including a 36-byte fixed bearer area or including a 1-byte adjustment area and a 35-byte fixed bearer area, or including a 1-byte adjustment area and a 34-byte fixed bearer area.

21. The bearer frame according to any one of claims 1 to 9, 13 to 17, wherein the first service is a TU12 service or a VC12 service and one of the bearer frames is used to carry one channel of the first service: A single bearer frame consists of one S-block, 72 D-blocks, and one T-block. The overhead region is located within the D-blocks, and the bearer region is located within the D-blocks and T-blocks. The bearer region includes either a 576-byte fixed bearer region, or a 1-byte adjustment region and a 575-byte fixed bearer region, or a 560-byte fixed bearer region, or a 1-byte adjustment region and a 559-byte fixed bearer region; or... A bearer frame consists of one S-block, 71 D-blocks, and one T-block. The overhead region is located in the S-block, and the bearer region is located in the S-block, D-block, and T-block. The bearer region includes a fixed bearer region of 576 bytes, or a fixed bearer region of 575 bytes including an adjustment region of 1 byte, or a fixed bearer region of 560 bytes, or a fixed bearer region of 559 bytes including an adjustment region of 1 byte.

22. The bearer frame according to any one of claims 1 to 9, 13 to 17, wherein the first service is a TU12 service or a VC12 service and one bearer frame is used to carry four channels of the first service: A single bearer frame consists of one S-block, 72 D-blocks, and one T-block. The overhead region is located within the D-blocks, and the bearer region is located within the D-blocks and T-blocks. The bearer region is divided into four groups, each group comprising either a 144-byte fixed bearer region, or a 1-byte adjustment region and a 143-byte fixed bearer region, or a 140-byte fixed bearer region, or a 1-byte adjustment region and a 139-byte fixed bearer region; or... A bearer frame consists of one S-block, 71 D-blocks, and one T-block. The overhead area is located in the S-block, and the bearer area is located in the S-block, D-block, and T-block. The bearer area is divided into four groups, each group including a 144-byte fixed bearer area, or including a 1-byte adjustment area and a 143-byte fixed bearer area, or including a 140-byte fixed bearer area, or including a 1-byte adjustment area and a 139-byte fixed bearer area.

23. The bearer frame according to any one of claims 1 to 9, 13 to 17, wherein the first service is a TU12 service or a VC12 service and one bearer frame is used to carry four channels of the first service: A single bearer frame consists of one S-block, 44 D-blocks, and one T-block. The overhead region is located within the D-blocks, and the bearer region is located within the D-blocks and T-blocks. The bearer region is divided into four groups, each group comprising either an 88-byte fixed bearer region or an adjustment region comprising one byte and an 87-byte fixed bearer region; or... A bearer frame consists of one S-block, 43 D-blocks and one T-block. The overhead area is located in the S-block, and the bearer area is located in the S-block, D-block and T-block. The bearer area is divided into four groups, each group including an 88-byte fixed bearer area or including an adjustment area of ​​one byte and an 87-byte fixed bearer area.

24. The bearer frame as described in any one of claims 1 to 9 and 18, wherein the first service is an AU4 service or a VC4 service and one of the bearer frames is used to carry one channel of the first service: A single bearer frame consists of one S-block, 120 D-blocks, and one T-block. The overhead region is located within the D-blocks, and the bearer region is located within the D-blocks and T-blocks. The bearer region includes a 962-byte fixed bearer region or includes a 1-byte adjustment region and a 961-byte fixed bearer region; or... A bearer frame consists of one S-block, 119 D-blocks and one T-block. The overhead area is located in the S-block, and the bearer area is located in the S-block, D-block and T-block. The bearer area includes a fixed bearer area of ​​962 bytes or includes an adjustment area of ​​1 byte and a fixed bearer area of ​​961 bytes.

25. A method for carrying a bearer frame based on any one of claims 1 to 24, applied at a transmitting end, comprising: Map the first service to be carried to the bearer frame; Map the bearer frame to the sub-slot; The sub-time slot is sent to the receiving end.

26. The bearer method of claim 25, wherein mapping the bearer frame to the sub-slot comprises: In the case that the first service is a TU12 service or a VC12 service, one or more of the bearer frames are mapped to a sub-time slot; Wherein, when one bearer frame is mapped to one sub-time slot, one bearer frame is used to carry multiple first services; when multiple bearer frames are mapped to one sub-time slot, each bearer frame is used to carry one first service or a portion of the services from multiple first services.

27. The bearer method of claim 26, wherein mapping the plurality of bearer frames into one sub-slot comprises: The multiple bearer frames are sequentially interleaved and mapped to a sub-slot after being interleaved in units of frames. or, The multiple bearer frames are sequentially interleaved and mapped into a sub-slot, using code blocks as the unit.

28. The bearer method of claim 25, wherein mapping the bearer frame to the sub-time slot comprises: In the case where one of the bearer frames is used to carry one AU4 service or VC4 service, one of the bearer frames is mapped to 15 or 16 of the sub-time slots.

29. A method for carrying a bearer frame based on any one of claims 1 to 24, applied at a receiving end, comprising: The sub-time slot transmitted by the receiving end; The sub-time slot is parsed to extract the bearer frame from the sub-time slot; The S-code block, D-code block, and T-code block in the bearer frame are parsed to extract the customer content of the first service carried by the bearer frame.

30. The bearer method as described in claim 29, wherein parsing the sub-time slot and extracting the bearer frame from the sub-time slot comprises: The carrier frames are extracted according to the interleaving order in units of frames to obtain multiple carrier frames; or, The code blocks are extracted according to the interleaving order in units of code blocks. The S code blocks, D code blocks and T code blocks corresponding to the same first service are merged to obtain multiple bearer frames.

31. An electronic device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 25 to 30.

32. A computer-readable storage medium, wherein instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the method as described in any one of claims 25 to 30.

33. A computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of the method as described in any one of claims 25 to 30.

Images