Overhead processing method and apparatus, and storage medium and electronic apparatus

Abstract

Provided in the embodiments of the present invention are an overhead processing method and apparatus, and a storage medium and an electronic apparatus. The method comprises: extracting a frame header indication overhead from a current service layer container; on the basis of the frame header indication overhead of the current service layer container, calculating an expected frame header indication overhead of the next service layer container, wherein the frame header indication overhead has a value other than 0x1FF; and comparing the expected frame header indication overhead with a frame header indication overhead extracted from the next service layer container, and if a first predetermined number of consecutive comparison results are consistent, entering a synchronization state, wherein the frame header indication overhead represents the number of byte blocks between a first new client service frame header and a starting boundary of the service layer container.

Description

Overhead processing method, device, storage medium and electronic device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present disclosure is based on Chinese patent application CN 202410030033.4 filed on January 8, 2024, entitled “Overhead processing method, device, storage medium and electronic device”, and claims the priority of the patent application, and all the disclosed contents are incorporated into the present disclosure by reference. Technical Field

[0003] The embodiments of the present disclosure relate to the field of communications, and in particular, to an overhead processing method, apparatus, storage medium, and electronic device. Background Art

[0004] The flexible OTN Digital Unit (fgODUflex) is a container used to carry small-granularity services in the optical transport network. VC-n (Virtual Container-n) is efficiently carried through fgODUflex. VC-n has a fixed frame length. When demapping customer services from fgODUflex, the VC-n frame structure boundary must be identified before the service is parsed. VC-n does not have overhead for framing, so fgODUflex defines a dedicated overhead to indicate the location of the VC-n frame header within the fgODUflex. During transmission, bit errors can cause overhead errors, preventing the VC-n structure boundary from being correctly identified and, consequently, preventing the parsing of customer services. Identifying these overhead errors is a problem that needs to be addressed.

[0005] Summary of the Invention

[0006] The embodiments of the present disclosure provide an overhead processing method, apparatus, storage medium, and electronic device to at least solve the problem of overhead errors caused by transmission errors in the related art.

[0007] According to an embodiment of the present disclosure, a method for overhead processing is provided, comprising: extracting a frame header indication overhead from a current service layer container; calculating an expected frame header indication overhead of a next service layer container based on the frame header indication overhead of the current service layer container, wherein the frame header indication overhead of the current service layer container is a value other than 0x1FF; comparing the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container, and entering a synchronization state if a first predetermined number of consecutive comparison results are consistent, wherein the frame header indication overhead represents the number of byte blocks between a first new client service frame header and a starting boundary of a service layer container.

[0008] In an exemplary embodiment, the expected frame header indication overhead value of the next service layer container is calculated based on at least one of: the length of the client service frame, the first number of client service byte blocks in the current service layer container, the second number of client service byte blocks in the next service layer container, and the frame header indication overhead of the current service layer container.

[0009] In an exemplary embodiment, calculating the expected frame header indication overhead of the next service layer container based on the frame header indication overhead of the current service layer container includes: determining the third number of byte blocks for carrying the client service frame in the current service layer container based on the frame header indication overhead of the current service layer container, the first number and the length of the client service frame; and determining the expected frame header indication overhead of the next service layer container based on the second number, the third number and the length of the client service frame.

[0010] In an exemplary embodiment, based on the frame header indication overhead of the current service layer container, the first quantity and the length of the client service frame determine the third quantity of byte blocks in the current service layer container for carrying client service frame blocks, including: determining a first remainder result of taking the remainder of the length of the client service frame by taking the remainder of the calculation result of the first quantity and the frame header indication overhead of the current service layer container; when the first remainder result is not 0, determining the third quantity as the remainder result; when the first remainder result is 0, determining the third quantity as the length of the client service frame.

[0011] In an exemplary embodiment, determining the expected frame header indication overhead of the next service layer container based on the second number, the third number, and the length of the client service frame includes: determining the fourth number of client service frame byte blocks carried by the next service layer container based on the third number and the length of the client service frame; when the fourth number is less than or equal to the first difference between the second number and a predetermined value, determining the expected frame header indication overhead of the next service layer container to be the fourth number; when the fourth number is greater than the first difference between the second number and the predetermined value, determining the expected frame header indication overhead of the next service layer container to be 0x1FF.

[0012] In an exemplary embodiment, the method further includes: when the fourth number is less than or equal to a first difference between the second number and a predetermined value, determining a fifth number of client service frame byte blocks carried by the next service layer container based on the expected frame header indication overhead of the next service layer container and the second number.

[0013] In an exemplary embodiment, determining the fifth number of client service frame byte blocks carried by the next service layer container based on the expected frame header indication overhead of the next service layer container and the second number includes: determining a second remainder result of taking the remainder of the length of the client service frame by taking the second difference between the second number and the expected frame header indication overhead of the next service layer container; and determining the fifth number based on the second remainder result.

[0014] In an exemplary embodiment, determining the fifth quantity based on the second remainder result includes: when the second remainder result is not 0, determining the fifth quantity as the second remainder result; when the second remainder result is 0, determining the fifth quantity as the length of the customer service frame.

[0015] In an exemplary embodiment, the method further includes: determining a sixth number of client service frame byte blocks carried by the next service layer container based on the third number and the second number when the fourth number is greater than a first difference between the second number and a predetermined value.

[0016] In an exemplary embodiment, the method further includes: using the calculated number of client service frame byte blocks carried by the next service layer container as the third number, and using the number of client service byte blocks carried in the subsequent service layer container as the second number, to determine the expected frame header indication overhead of the subsequent service layer container.

[0017] According to another embodiment of the present disclosure, an overhead processing method is provided, including: extracting a first overhead and a second overhead from a target service layer container, wherein the first overhead and the second overhead are two adjacent overheads, and the first overhead and the second overhead are both used to indicate the reframe information of the service layer container; when it is determined that the values ​​of the first overhead and the second overhead are the same and the third overhead corresponding to the value of the first overhead is a value other than 0b111, or when the values ​​of the first overhead and the second overhead conform to a preset sequence and the third overhead corresponding to the value of the first overhead is 0b111, entering a synchronization state.

[0018] In an exemplary embodiment, the preset sequence includes 0 to 10 cycles.

[0019] According to another embodiment of the present disclosure, an overhead processing device is provided, including: a first extraction module, configured to extract a frame header indication overhead from a current service layer container; a calculation module, configured to calculate an expected frame header indication overhead of a next service layer container based on the frame header indication overhead of the current service layer container, wherein the frame header indication overhead of the current service layer container is a value other than 0x1FF; a comparison module, configured to compare the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container, and if a first predetermined number of consecutive comparison results are consistent, entering a synchronization state, wherein the frame header indication overhead represents the number of byte blocks between the first new client service frame header and the starting boundary of the service layer container.

[0020] According to another embodiment of the present disclosure, an overhead processing device is provided, including: a second extraction module, configured to extract a first overhead and a second overhead from a target service layer container, wherein the first overhead and the second overhead are two adjacent overheads, and the first overhead and the second overhead are both used to indicate the multi-frame information of the service layer container; a synchronization module, configured to enter a synchronization state when it is determined that the values ​​of the first overhead and the second overhead are the same and the third overhead corresponding to the value of the first overhead is a value other than 0b111, or when the values ​​of the first overhead and the second overhead conform to a preset sequence and the third overhead corresponding to the value of the first overhead is 0b111.

[0021] According to another embodiment of the present disclosure, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when running.

[0022] According to another embodiment of the present disclosure, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] FIG1 is a hardware structure block diagram of a mobile terminal according to an overhead processing method of an embodiment of the present disclosure;

[0024] FIG2 is a flowchart of a method for processing overhead according to an embodiment of the present disclosure;

[0025] FIG3 is a second flowchart of the overhead processing method according to an embodiment of the present disclosure;

[0026] FIG4 is a structural block diagram 1 of an overhead processing apparatus according to an embodiment of the present disclosure;

[0027] FIG5 is a second structural block diagram of the overhead processing apparatus according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0028] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings and in conjunction with embodiments.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0030] First, the related technologies involved in this disclosure are described:

[0031] The Optical Transport Network (OTN) is primarily used to carry large-granularity services above 1G. Carrying customer services below 1G results in bandwidth waste. For example, carrying a 10M service on a 1.25G ODU0 (Optical Channel Data Unit 0) results in significant bandwidth waste. To better support the carriage of customer services below 1G, international standards organizations are discussing fgOTN (flexible grid Optical Transport Network) technology. fgOTN is an extension of existing OTN technology, capable of efficiently supporting customer services below 1G, and related technical discussions have converged. During the fgOTN discussion, specialized overhead was defined for carrying customer services below 1G. Detecting this overhead and handling subsequent alarms will be key points of discussion for fgOTN.

[0032] fgODUflex is a container used to carry small-granularity services in the optical transport network. Low-speed client services such as E1 (E-carrier Level 1), VC-n, FE (Fast Ethernet), and STM-1 (Synchronous Transport Module Level 1) are efficiently carried through fgODUflex. Client services have specific structural characteristics. VC-n and STM-1 services have fixed frame lengths, while Ethernet services consist of 66-bit frames. Regardless of the frame structure or the 66-bit structure, demapping client services from fgODUflex requires identifying structure boundaries before service parsing. STM-1 services have a frame header indicator signal. After demapping the STM-1 from fgODUflex, STM-1 frame boundaries can be identified based on STM-1 framing. However, VC-n services do not have framing overhead. Currently under discussion, a dedicated overhead is defined in fgODUflex to indicate the location of the VC-n frame header within the fgODUflex. Although IEEE 802.3 specifies 66b boundary location and processing for Ethernet services based on 66b, the Ethernet service rates carried by fgODUflex are relatively low. Performing 66b boundary location according to the IEEE 802.3 definition would result in significant processing delays. Therefore, fgOTN technology also defines overhead to identify 66b boundaries and speed up boundary identification. During transmission, errors in these overheads can occur due to bit errors. These errors prevent the structural boundaries of customer services from being correctly identified, hindering proper service resolution. Identifying these overhead errors is a critical issue that needs to be addressed.

[0033] In view of the above problems existing in the related art, corresponding solutions are proposed in the embodiments of the present disclosure. The present disclosure is described below with reference to the embodiments:

[0034] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking operation on a mobile terminal as an example, FIG1 is a hardware structure block diagram of a mobile terminal according to the overhead processing method of an embodiment of the present disclosure. As shown in FIG1 , the mobile terminal may include one or more (only one is shown in FIG1 ) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 configured to store data, wherein the mobile terminal may also include a transmission device 106 and an input / output device 108 configured to have a communication function. It will be understood by those skilled in the art that the structure shown in FIG1 is only for illustration and does not limit the structure of the mobile terminal. For example, the mobile terminal may also include more or fewer components than those shown in FIG1 , or have a configuration different from that shown in FIG1 .

[0035] The memory 104 can be configured to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the overhead processing method in the embodiment of the present disclosure. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0036] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the mobile terminal's telecommunications provider. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one embodiment, the transmission device 106 may be a radio frequency (RF) module configured to communicate with the Internet wirelessly.

[0037] In this embodiment, a method for processing overhead is provided. FIG2 is a flowchart of the method for processing overhead according to an embodiment of the present disclosure. As shown in FIG2 , the flowchart includes the following steps:

[0038] Step S202: extracting the frame header indication overhead from the current service layer container;

[0039] Step S204: Calculate the expected frame header indication overhead of the next service layer container based on the frame header indication overhead of the current service layer container, wherein the frame header indication overhead of the current service layer container is a value other than 0x1FF;

[0040] Step S206: compare the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container. If the comparison results are consistent for the first predetermined number of consecutive times, enter the synchronization state, wherein the frame header indication overhead represents the number of byte blocks between the first new client service frame header and the starting boundary of the service layer container.

[0041] In the above embodiment, the application scenarios of the processing method include but are not limited to VC-n services. The delivery method for VC-n services is as follows:

[0042] On the transmitting side, VC-n services are mapped into the payload area of ​​the fgODUflex frame in accordance with methods including, but not limited to, the Group Management Protocol (GMP). The mapping process includes, but is not limited to, processing two lines of an fgODUflex frame as one mapped payload area. A VC-n client service frame may be mapped into one mapped payload area or across two or more mapped payload areas. After the mapping of the VC-n client service in the previous mapped payload area is completed, the amount of 16-byte data (X) carried by a VC-n frame in the previous mapped payload area and the amount of 16-byte data (Y) required to be carried in the current mapped payload area are determined. The amount of 16-byte client service data that can be carried by each mapped payload area includes, but is not limited to, Code 128 (C128). If Y is less than or equal to C128-1, it indicates that the next VC-n service frame header will appear in the current mapped payload area. In this case, the Y value is used as the content of the CFS (Client Frame Start) overhead (i.e., the frame header indication overhead of the current server layer container mentioned above). Because GMP mapping adds 16 bytes of padding blocks, the position of the next VC-n frame header in the mapped payload area is not necessarily Y+1. If Y is greater than C128-1, it indicates that the next VC-n client service frame header will not appear in the current mapped payload area. The CFS is padded with a fixed value of 0x1FF. The byte blocks include data blocks and padding blocks.

[0043] On the receiving side, the 16-byte data block used to carry the VC-n client service in the mapped payload area and the 16-byte padding block are calculated based on the GMP mapping overhead in a manner including but not limited to the sigma-delta algorithm. The VC-n client service is extracted from the 16-byte data block in the mapped payload area, and the VC-n frame boundary is identified based on the CFS (Client Service Frame Header Start) overhead in the fgODUflex frame. However, the service delivery process is affected by bit errors, which can cause CFS overhead errors, thereby affecting the frame boundary identification of the VC-n client service. The CFS overhead needs to be detected and processed. The CFS overhead detection process has two states: one is a synchronous state and the other is an out-of-sync state. The current CFS overhead value is extracted from the overhead of the fgODUflex frame. If the CFS value is 0x1FF, the next CFS overhead value is extracted until a non-0x1FF CFS overhead value Y(i) is obtained. Based on this CFS overhead value, the next expected CFS overhead value E(i+1) is predicted. The next expected CFS overhead value is determined by the current CFS overhead value Y(i), the frame length L of the VC-n client service, the number of 16-byte data blocks C128(i) used to carry the VC-n client service in the current mapped payload area, and the number of 16-byte data blocks C128(i+1) used to carry the VC-n client service in the next mapped payload area.

[0044] The VC-n service has different frame lengths depending on the service type. Exemplarily, the frame lengths include but are not limited to 32 bytes, 64 bytes, 128 bytes, 144 bytes, 192 bytes, 576 bytes, etc. In the application scenario of the present disclosure, preferably, the frame length of the VC-n service is 144 bytes (i.e., 9 times 16 bytes). For the same type of VC-n service, there may be a need to cascade v VC-n frames for transmission. The frame length of the cascaded VC-n client service is also increased by v times.

[0045] In the above steps, the frame header indication overhead of the current service layer container and the frame header indication overhead of the next service layer container include but are not limited to: CFS (Client Frame Start). The current service layer container and the next service layer container include but are not limited to: the payload area of ​​fgODUflex. The byte block is but is not limited to a 16-byte block. The first predetermined number is but is not limited to: 2 times, 3 times, 4 times, etc. The first predetermined number can be set according to the application scenario. The execution scenario of the above steps includes but is not limited to: the out-of-sync state of the CFS overhead detection processing.

[0046] The execution subject of the above steps may be a base station, a terminal, etc., or a specific network element or node on the network side, or other equipment with similar processing capabilities, but is not limited thereto.

[0047] Through the above steps, since the expected overhead of each layer is calculated layer by layer and the calculated expected overhead is compared with the actual overhead extracted from the layer, accurate identification of overhead errors can be achieved. Therefore, the problem of overhead errors caused by transmission errors in related technologies can be solved, thereby achieving the effect of improving the accuracy of the determined overhead, so that the boundary structure of the customer service can be accurately identified.

[0048] In an optional embodiment, the expected frame header indication overhead value of the next service layer container is calculated by at least one of the following: the length of the customer service frame, the first number of customer service byte blocks used to carry the customer service byte blocks in the current service layer container, the second number of customer service byte blocks used to carry the customer service byte blocks in the next service layer container, and the frame header indication overhead of the current service layer container.

[0049] In the above steps, the sizes of the current service layer container and the next service layer container include, but are not limited to, 105 bytes, 106 bytes, and the like. Exemplarily, the length of the client service frame is in units of 16 bytes, and the length of the client service frame includes, but is not limited to, 144 bytes, i.e., nine 16-byte units. Furthermore, the lengths of the multiple client service frames mapped from the client service are generally the same.

[0050] In an optional embodiment, calculating the expected frame header indication overhead of the next service layer container based on the frame header indication overhead of the current service layer container includes: determining the third number of byte blocks for carrying the client service frame in the current service layer container based on the frame header indication overhead of the current service layer container, the first number and the length of the client service frame; and determining the expected frame header indication overhead of the next service layer container based on the second number, the third number and the length of the client service frame.

[0051] In the above steps, the third number is the number of byte blocks remaining that are insufficient to transmit a complete client service frame after the current service layer container completes the transmission of one or more new complete client service frames, that is, the number of partial byte blocks that carry a complete client service frame.

[0052] In an optional embodiment, based on the frame header indication overhead of the current service layer container, the first quantity and the length of the client service frame determine the third quantity of byte blocks in the current service layer container for carrying the client service frame, including: determining a first remainder result of taking the remainder of the length of the client service frame by taking the remainder of the calculation result of the first quantity and the frame header indication overhead of the current service layer container; when the first remainder result is not 0, determining the third quantity as the remainder result; when the first remainder result is 0, determining the third quantity as the length of the client service frame.

[0053] In the above steps, determining the calculation result of the first number and the current frame header indication overhead includes but is not limited to: obtaining the calculation result by subtraction. Exemplarily, determining the difference between the first number and the current frame header indication overhead as the calculation result.

[0054] The above method is described as follows in conjunction with the embodiments:

[0055] Example 1:

[0056] First, the relevant parameters in the embodiment are explained: Y(i) is used to represent the CFS overhead value (i.e., the frame header indication overhead of the current service layer container mentioned above), L is used to represent the frame length of the customer service, C128(i) is used to represent the number of 16 bytes used to carry the VC-n service in the current i-th mapping payload area (i.e., the first number mentioned above), and X(i) is used to represent the number of 16 bytes of the VC-n customer service frame carried in the current i-th mapping payload area (i.e., the third number mentioned above), where i is an integer greater than zero.

[0057] Determine the number of 16 bytes X(i) of VC-n client service frames carried in the current i-th mapped payload area based on the current non-0x1FF CFS overhead value Y(i), the frame length L of the VC-n client service (in units of 16 bytes), and the number of 16 bytes C128(i) used to carry the VC-n service in the current i-th mapped payload area.

[0058] When the remaining 16-byte quantity C128(i)-Y(i) used to carry VC-n data in the i-th mapped payload area is greater than L, that is, after the i-th mapped payload area has completed carrying the last complete TU-12 frame, the 16-byte quantity available for carrying VC-n client services can carry one or more VC-n client service frames. The 16-byte quantity X(i) of the last complete VC-n client service frame carried in the current i-th mapped payload area is determined by taking the modulus of (C128(i)-Y(i)) and the VC-n client service frame length L. If the modulus result is not 0, then X(i)=(C128(i)-Y(i)) mod L; otherwise, X(i)=L.

[0059] When the remaining 16 bytes C128(i)-Y(i) used to carry VC-n data in the i-th mapped payload area is less than or equal to L, that is, after the i-th mapped payload area completes carrying the previous complete TU-12 frame, the remaining 16 bytes are insufficient to carry a VC-n client service frame or just carry a VC-n client service frame. After the VC-n client service is mapped to the current i-th mapped payload area, the number of 16 bytes X(i) carried by the i-th mapped payload area for a complete VC-n client service frame is equal to C128(i)-Y(i). The value of X(i) is greater than or equal to 1 and less than or equal to L.

[0060] The following is an explanation of the above steps using the formula:

[0061] If C128(i)-Y(i)>L;

[0062] If (C128(i)-Y(i))mod L≠0;

[0063] Then X(i)=(C128(i)-Y(i))mod L;

[0064] Otherwise X(i) = L;

[0065] If C128(i)-Y(i)≤L;

[0066] Then X(i)=C128(i)-Y(i).

[0067] Example 2:

[0068] First, the relevant parameters in the embodiment are explained: Y(i) is used to represent the CFS overhead value (i.e., the frame header indication overhead of the current service layer container mentioned above), L is used to represent the frame length of the customer service, C128(i) is used to represent the number of 16 bytes used to carry the VC-n service in the current i-th mapping payload area (i.e., the first number mentioned above), and X(i) is used to represent the number of 16 bytes of the VC-n customer service frame carried in the current i-th mapping payload area (i.e., the third number mentioned above), where i is an integer greater than zero.

[0069] Determine the number of 16 bytes X(i) of VC-n client service frames carried in the current i-th mapped payload area based on the current non-0x1FF CFS overhead value Y(i), the frame length L of the VC-n client service (in units of 16 bytes), and the number of 16 bytes C128(i) used to carry the VC-n service in the current i-th mapped payload area.

[0070] The 16-byte number X(i) of the last complete VC-n client service frame carried in the current i-th mapped payload area is determined by taking the modulus of (C128(i)-Y(i)) and the VC-n client service frame length L. If the modulus is not 0, then X(i) = (C128(i)-Y(i)) mod L; otherwise, X(i) = L.

[0071] The following is an explanation of the above steps using the formula:

[0072] If (C128(i)-Y(i)) mod L ≠ 0

[0073] Then X(i)=(C128(i)-Y(i))mod L

[0074] Otherwise X(i)=L

[0075] In an optional embodiment, determining the expected frame header indication overhead of the next service layer container based on the second number, the third number, and the length of the client service frame includes: determining the fourth number of client service frame byte blocks carried by the next service layer container based on the third number and the length of the client service frame; when the fourth number is less than or equal to the first difference between the second number and the predetermined value, determining the expected frame header indication overhead of the next service layer container to be the fourth number; when the fourth number is greater than the first difference between the second number and the predetermined value, determining the expected frame header indication overhead of the next service layer container to be 0x1FF.

[0076] In an optional embodiment, the method further includes: when the fourth number is less than or equal to a first difference between the second number and a predetermined value, determining a fifth number of client service frame byte blocks carried by the next service layer container based on the expected frame header indication overhead of the next service layer container and the second number.

[0077] In the above steps, the fifth number is the number of byte blocks that remain after the next service layer container completes the transmission of the current and new one or more complete client service frames, which is less than the number of byte blocks that carry a complete client service frame.

[0078] In an optional embodiment, determining the fifth number of client service frame byte blocks carried by the next service layer container based on the expected frame header indication overhead of the next service layer container and the second number includes: determining a second remainder result of taking the remainder of the length of the client service frame by taking the second difference between the second number and the expected frame header indication overhead of the next service layer container; and determining the fifth number based on the second remainder result.

[0079] In an optional embodiment, determining the fifth quantity based on the second remainder result includes: when the second remainder result is not 0, determining the fifth quantity as the second remainder result; when the second remainder result is 0, determining the fifth quantity as the length of the customer service frame.

[0080] In an optional embodiment, the method further includes: determining a sixth number of customer service frame byte blocks carried by the next service layer container based on the third number and the second number when the fourth number is greater than a first difference between the second number and a predetermined value.

[0081] The above method is described as follows in conjunction with specific embodiments:

[0082] Example 3:

[0083] First, the relevant parameters in the embodiment are explained: Y(i) is used to represent the CFS overhead value (i.e., the aforementioned frame header indication overhead of the current service layer container), L is used to represent the frame length of the client service, C128(i) is used to represent the number of 16 bytes used to carry the VC-n service in the current i-th mapping payload area (i.e., the aforementioned first number), C128(i+1) is used to represent the number of 16 bytes used to carry the VC-n service in the current i+1-th mapping payload area (i.e., the aforementioned second number), X(i) is used to represent the number of 16 bytes of the VC-n client service frame carried in the current i-th mapping payload area (i.e., the aforementioned third number), and E(i+1) is used to represent the CFS expected value E(i+1) corresponding to the i+1-th mapping payload area (i.e., the aforementioned expected frame header indication overhead), where i is an integer greater than zero.

[0084] Based on X(i) calculated in the first embodiment and the length L of the VC-n client service frame, the CFS expected value E(i+1) and X(i+1) corresponding to the i+1th mapped payload area are determined.

[0085] When (L–X(i)) is less than or equal to (C128(i+1)-1), that is, the frame header of the client service VC-n appears in the i+1th mapped payload area, then E(i+1) = L–X(i). The value of the 16-byte number X(i+1) of the last complete VC-n client service frame carried in the i+1th mapped payload area is determined by the 16-byte number C128(i+1) and E(i+1) used to carry the VC-n service in the i+1th mapped payload area. If the modulus of (C128(i+1)-E(i+1)) with respect to the VC-n client service frame length L is not zero, then X(i+1) = (C128(i+1)-E(i+1)) mod L. Otherwise, X(i+1) = L.

[0086] When (L–X(i)) is greater than (C128(i+1)-1), that is, the i+1 mapped payload area does not contain the client service VC-n frame header, then E(i+1) = 0x1FF, and the number of 16 bytes carried by the i+1th mapped payload area and the previous mapped payload areas in a complete VC-n client service frame is X(i+1) = C128(i)-Y(i)+C128(i+1).

[0087] The following is an explanation of the above steps using the formula:

[0088] If L–X(i)≤C128(i+1)-1

[0089] Then E(i+1)=L–X(i),

[0090] If (C128(i+1)-E(i+1)) mod L ≠ 0

[0091] X(i+1)=(C128(i+1)-E(i+1))mod L

[0092] Otherwise X(i+1)=L

[0093] If L–X(i)>C128(i+1)-1

[0094] Then E(i+1)=0x1FF, X(i+1)=C128(i)-Y(i)+C128(i+1)

[0095] Example 4:

[0096] First, the relevant parameters in the embodiment are explained: Y(i) is used to represent the CFS overhead value (i.e., the aforementioned frame header indication overhead of the current service layer container), L is used to represent the frame length of the client service, C128(i) is used to represent the number of 16 bytes used to carry the VC-n service in the current i-th mapping payload area (i.e., the aforementioned first number), C128(i+1) is used to represent the number of 16 bytes used to carry the VC-n service in the current i+1-th mapping payload area (i.e., the aforementioned second number), X(i) is used to represent the number of 16 bytes of the VC-n client service frame carried in the current i-th mapping payload area (i.e., the aforementioned third number), and E(i+1) is used to represent the CFS expected value E(i+1) corresponding to the i+1-th mapping payload area (i.e., the aforementioned expected frame header indication overhead), where i is an integer greater than zero.

[0097] According to X(i) calculated in the above embodiment and the length L of the VC-n client service frame, the CFS expected value E(i+1) and X(i+1) corresponding to the i+1th mapped payload area are determined.

[0098] When (L–X(i)) is less than or equal to (C128(i+1)-1), that is, the frame header of the client service VC-n appears in the i+1th mapped payload area, then E(i+1) = L–X(i). The value of the 16-byte number X(i+1) of the last complete VC-n client service frame carried in the i+1th mapped payload area is determined by the 16-byte number C128(i+1) and E(i+1) used to carry the VC-n service in the i+1th mapped payload area. If the modulus of (C128(i+1)-E(i+1)) with respect to the VC-n client service frame length L is not zero, then X(i+1) = (C128(i+1)-E(i+1)) mod L. Otherwise, X(i+1) = L.

[0099] When (L–X(i)) is greater than (C128(i+1)-1), that is, the i+1 mapped payload area does not contain the client service VC-n frame header, then E(i+1) = 0x1FF, and the number of 16 bytes carried by the i+1th mapped payload area and the previous mapped payload areas in a complete VC-n client service frame is X(i+1) = C128(i)-Y(i)+C128(i+1).

[0100] The following is an explanation of the above steps using the formula:

[0101] If L–X(i)≤C128(i+1)-1

[0102] Then E(i+1)=L–X(i),

[0103] If (C128(i+1)-E(i+1)) mod L ≠ 0

[0104] X(i+1)=(C128(i+1)-E(i+1))mod L

[0105] Otherwise X(i+1)=L

[0106] If L–X(i)>C128(i+1)-1

[0107] Then E(i+1)=0x1FF, X(i+1)=[C128(i)-Y(i)]+C128(i+1)

[0108] In an optional embodiment, the method further includes: using the calculated number of customer service frame byte blocks carried by the next service layer container as the third number, and using the number of customer service byte blocks used to carry the subsequent service layer container as the second number to determine the expected frame header indication overhead of the subsequent service layer container.

[0109] In the above embodiment, by repeatedly executing the steps in the above embodiment, the expected overhead value (i.e., the aforementioned CFS expected value) in all subsequent service layer containers can be calculated. Specifically, this can be achieved by setting i in the above embodiment to i+1. In the out-of-sync state, starting from the first non-0x1FF CFS overhead value received, if the CFS overhead value received for N consecutive times is the same as the expected value, the synchronization state is entered. In the synchronization state, when the calculated CFS expected value and the extracted CFS overhead value are inconsistent, the frame boundary of the VC-n service is identified according to the calculated CFS expected value, and the next CFS expected value is calculated based on the CFS expected value. In the synchronization state, when the CFS overhead value received for M consecutive times is different from the expected value, the out-of-sync state is entered and a CFS loss alarm is generated. The CFS loss alarm triggers the generation of a maintenance signal for the VC-n customer service. N and M are integers greater than or equal to 1.

[0110] The following is an overall description of the solution of the present disclosure in conjunction with specific embodiments:

[0111] Specific embodiment one:

[0112] In this specific embodiment, the source node and the sink node transmit a TU-12 (Tributary Unit-12, 12x speed tributary unit, one TU-12 can contain one or more VC-12) service through fgODUflex. The overall process includes the following steps:

[0113] Step 1: At the source node, parse the TU-12 from the STM interface. The TU-12 multiframe is 144 bytes. The TU-12 is mapped to the two-line mapped payload area of ​​the fgODUflex frame using GMP, and the CFS overhead is inserted. The TU-12 multiframe length is L = 9 16-bytes. The number of 16 bytes used to carry the TU-12 frame in the two-line mapped payload area of ​​the fgODUflex is 105 and 106. Therefore, the TU-12 frame header appears in each two-line mapped payload area of ​​the fgODUflex. That is, the CFS value will not be 0x1FF. The default CFS overhead is out of sync, and CFS overhead synchronization is performed.

[0114] Step 2. At the sink node, extract the CFS value Y(i) = 6 from the overhead corresponding to the 2-row mapped payload area of ​​the i-th fgODUflex frame. The 2-row mapped payload area of ​​the i-th fgODUflex frame is used to carry the number of 16-byte data blocks C128(i) = 105 of the TU-12 frame, which is carried in the GMP overhead position corresponding to the 2-row mapped payload area of ​​the i-1-th fgODUflex frame.

[0115] In step 3, the remaining 16 bytes of the TU-12 frame that can be carried in the two-row mapped payload area of ​​the i-th fgODUflex frame are C128(i)-Y(i)=105–6=99 16 bytes. The length of the TU-12 frame is L=9 16 bytes, and C128(i)-Y(i)>L, meaning that 99 16 bytes can carry exactly 11 complete TU-12 frames. Since (C128(i)-Y(i)) mod L=(105–6) mod 9=0, the two-row mapped payload area of ​​the i-th fgODUflex frame is used to carry the 16 bytes of the last complete TU-12 frame, X(i)=L=9, indicating that a complete TU-12 frame has been transmitted.

[0116] In step 4, the GMP overhead corresponding to the two-row mapped payload area of ​​the i-th fgODUflex frame is used to extract the number of 16-byte data blocks of the TU-12 frame carried by the two-row mapped payload area of ​​the i+1-th fgODUflex frame, C128(i+1) = 106. Based on the number X(i) = 9 used by the two-row mapped payload area of ​​the i-th fgODUflex frame in step 3 to carry the last complete TU-12 frame and the length of the TU-12 frame (9 16-byte blocks), since L–X(i) = 0 < (C128(i+1) - 1) = 105, indicating that multiple TU-12 frames can be carried, the CFS expected overhead value E(i+1) corresponding to the two-row mapped payload area of ​​the i+1-th fgODUflex frame is = L–X(i) = 9 - 9 = 0.

[0117] In step 5, the remaining 16 bytes in the two-row mapped payload area of ​​the i+1th fgODUflex frame that can be used to carry a TU-12 frame are C128(i+1)-E(i+1)=106–0=106 16 bytes. C128(i+1)-E(i+1)>L, meaning that 106 16 bytes can carry 11 complete TU-12 frames plus the first 7 bytes of a complete TU-12 frame. In other words, the number of 16 bytes in the two-row mapped payload area of ​​the i+1th fgODUflex frame that can be used to carry the last complete TU-12 frame is X(i+1)=(C128(i+1)-E(i+1))modL=(106–0)mod9=7.

[0118] In step 6, change i to i+1 and repeat steps 4 and 5 to calculate the expected values ​​of the CFS costs of the i+2th, i+3th, and so on.

[0119] Step 7: If the CFS overhead value and the CFS expected value received are the same for two consecutive times, the synchronization state is entered. The CFS value is used to identify the TU-12 frame header and the CFS overhead value is continuously compared with the CFS expected value.

[0120] In step 8, if the received CFS overhead value differs from the expected CFS value for five consecutive times in the synchronized state, the system enters the out-of-sync state and generates a CFS loss alarm. This alarm triggers the use of maintenance signals to replace the normal TU-12 signals. CFS synchronization processing continues from step 2 until the system enters the synchronized state.

[0121] Specific embodiment two:

[0122] Step 1: At the source node, 60 TU-12s are parsed from the STM interface and interleaved byte by byte into a single data stream. The TU-12 multiframe length is 144 bytes. The interleaved TU-12 data stream is mapped into the two-row mapped payload area of ​​the fgODUflex frame using GMP, and the CFS overhead is inserted. The TU-12 multiframe length is nine 16-byte segments, and the length of the 60xTU-12 data frame after the 60 TU-12s are interleaved is L = 9 * 60 = 540 16-byte segments. The number of 16-byte segments used to carry the interleaved 60xTU-12 data frame in the two-row mapped payload area of ​​the fgODUflex is 453 or 454. If a 60xTU-12 data frame header is missing from the two-row mapped payload area of ​​the fgODUflex, the CFS value will be 0x1FF. By default, the CFS overhead is out of sync, and CFS overhead synchronization is performed.

[0123] Step 2. At the sink node, extract the CFS value from the overhead corresponding to the 2-row mapped payload area of ​​the fgODUflex frame until a CFS overhead value other than 0x1FF is extracted. Assume that the CFS value Y(i) = 450 is extracted from the overhead corresponding to the 2-row mapped payload area of ​​the i-th fgODUflex frame, and the 2-row mapped payload area of ​​the i-th fgODUflex frame is used to carry the number of 16-byte data blocks C128(i) = 453 of the interleaved 60xTU-12 data frame in the GMP overhead position corresponding to the 2-row mapped payload area of ​​the i-1-th fgODUflex frame.

[0124] In step 3, the remaining 16 bytes of the interleaved 60xTU-12 data frame that can be carried in the two-row mapped payload area of ​​the i-th fgODUflex frame are C128(i) - Y(i) = 453 – 450 = 3 16 bytes. The length of the interleaved 60xTU-12 data frame is L = 540 16 bytes, and C128(i) - Y(i) < L, meaning that the remaining 3 16 bytes are insufficient to carry a complete interleaved 60xTU-12 data frame. The remaining 16 bytes of the two-row mapped payload area of ​​the i-th fgODUflex frame that can be used to carry the last complete interleaved 60xTU-12 data frame are X(i) = C128(i) - Y(i) = 453 – 450 = 3, indicating that they carry the first 3 16 bytes of the last complete interleaved 60xTU-12 data frame.

[0125] Step 4: Extract the number of 16-byte data blocks C128(i+1)=454 of the 2-row mapped payload area of ​​the (i+1)th fgODUflex frame used to carry the interleaved 60xTU-12 data frame from the GMP overhead corresponding to the 2-row mapped payload area of ​​the (i+1)th fgODUflex frame. Based on the number X(i) = 3 of the last complete interleaved 60xTU-12 data frame carried by the two-row mapped payload area of ​​the i-th fgODUflex frame in step 3 and the length L of the interleaved 60xTU-12 data frame (540 16-byte frames), L – X(i) = 540 – 3 = 537 > C128(i+1) - 1 = 454 – 1 = 453. This indicates that the two-row mapped payload area of ​​the i+1-th fgODUflex frame is insufficient to carry the remaining 537 bytes of the last complete interleaved 60xTU-12 data frame of the i-th frame. That is, the two-row mapped payload area of ​​the i+1-th fgODUflex frame does not contain the header of the next interleaved 60xTU-12 data frame. Therefore, the CFS expected overhead value E(i+1) corresponding to the two-row mapped payload area of ​​the i+1-th fgODUflex frame is 0x1FF.

[0126] In step 5, the two-row mapped payload area of ​​the (i+1)th fgODUflex frame can be used to carry 454 16-bytes of the interleaved 60xTU-12 data frame. That is, after the interleaved 60xTU-12 data frame is mapped to the two-row mapped payload area of ​​the (i+1)th fgODUflex frame, the number of 16-bytes of the two-row mapped payload area of ​​the fgODUflex frame in a complete interleaved 60xTU-12 data frame is X(i+1) = C128(i) - Y(i) + C128(i+1) = 453 - 450 + 454 = 457.

[0127] In step 6, change i to i+1 and repeat steps 4 and 5 to calculate the expected values ​​of the CFS costs of the i+2th, i+3th, and so on.

[0128] Step 7: If the CFS overhead value and the CFS expected value received are the same for two consecutive times, the synchronization state is entered. The CFS value is used to identify the frame header of the interleaved 60xTU-12 data frame and the CFS overhead value is continuously compared with the CFS expected value.

[0129] In step 8, if the received CFS overhead value differs from the expected CFS value for five consecutive times in the synchronized state, the system enters the out-of-sync state and generates a CFS loss alarm. This alarm triggers the use of a maintenance signal to replace the normal interleaved 60xTU-12 data frame signal. CFS synchronization processing continues from step 2 until the system enters the synchronized state.

[0130] FIG3 is a second flowchart of the overhead processing method according to an embodiment of the present disclosure. As shown in FIG3 , the process includes the following steps:

[0131] Step S302: extracting a first overhead and a second overhead from a target service layer container, wherein the first overhead and the second overhead are two adjacent overheads, and both the first overhead and the second overhead are used to indicate multiframe information of the service layer container;

[0132] Step S304: Enter the synchronization state when it is determined that the values ​​of the first overhead and the second overhead are the same and the third overhead corresponding to the value of the first overhead is a value other than 0b111, or when the values ​​of the first overhead and the second overhead conform to a preset sequence and the third overhead corresponding to the value of the first overhead is 0b111.

[0133] In the above embodiment, the application scenarios of the processing method include but are not limited to Ethernet services. The transmission method for Ethernet services is as follows:

[0134] On the transmitting side, Ethernet services are mapped to the payload area of ​​the fgODUflex frame using the IMP (Interface Mapping Processor). The Ethernet service has a 66-bit structure. The first bit of the first 66-bit code block in the Ethernet client service flow is mapped to the first bit of the payload area of ​​the first fgODUflex frame. The last bit of the 20224th 66-bit code block is mapped to the last bit of the payload area of ​​the 11th fgODUflex frame. This mapping process is repeated in sequence. The Optical Multiplex Frame Identifier (OMFI) overhead is used to count the cycles of the 11 fgODUflex frames. Eight OMFI overheads are defined in each fgODUflex frame, and these OMFI overheads have the same value.

[0135] On the receiving side, the fgODUflex payload extracts Ethernet client services and identifies 66b boundaries of Ethernet services based on the OMFI overhead in the fgODUflex frame. However, bit errors can affect the delivery of services, which can cause OMFI overhead errors and affect the identification of 66b boundaries of Ethernet services. OMFI overhead detection requires processing, which operates in two states: in-sync and out-of-sync.

[0136] In the above embodiment, the target service layer container includes but is not limited to: fgODUflex payload area, and in the out-of-sync state, the OMFI overhead value is detected. The first overhead is located before the second overhead. If it is detected that the two adjacent OMFI overhead values ​​are the same and the HRN corresponding to the first OMFI overhead value is not 0b111, or if it is detected that the two adjacent OMFI overhead values ​​conform to the preset sequence and the HRN corresponding to the first OMFI value is 0b111, then the synchronization state is entered. The preset sequence is a continuous cycle from 0 to 10. After entering the synchronization state, the position of fgODUflex in the OMFI multiframe can be known according to the corresponding OMFI value, thereby determining the 66b boundary.

[0137] In the synchronized state, if two adjacent OMFI overhead values ​​are detected to be different when the HRN corresponding to the first OMFI overhead value is not 0b111, or if two adjacent OMFI overhead values ​​are detected to be out of sequence when the HRN corresponding to the first OMFI overhead value is 0b111, these two situations are considered abnormal. If these abnormalities occur Z times in a row, the frame enters the out-of-sync state. After the out-of-sync state persists for a period of time, an OMFI loss alarm is generated. The OMFI loss alarm triggers a maintenance signal for the Ethernet client service. Z is an integer greater than or equal to 1. The OMFI start of the fgODUflex frame should be maintained during the OMFI out-of-sync period.

[0138] Through the above steps, since adjacent overheads in the same service layer are compared, accurate identification of overhead errors can be achieved. Therefore, the problem of overhead errors caused by transmission errors in related technologies can be solved, thereby improving the accuracy of the determined overhead, thereby achieving the effect of accurately identifying the boundary structure of the customer service.

[0139] In an optional embodiment, the preset sequence includes cycles from 0 to 10.

[0140] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present disclosure.

[0141] This embodiment also provides an overhead processing device for implementing the above-mentioned embodiments and preferred implementations. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0142] Figure 4 is a structural block diagram 1 of an overhead processing device according to an embodiment of the present disclosure. As shown in Figure 4, the device includes: a first extraction module 42, configured to extract a frame header indication overhead from a current service layer container; a calculation module 44, configured to calculate an expected frame header indication overhead of a next service layer container based on the frame header indication overhead of the current service layer container, wherein the frame header indication overhead of the current service layer container is a value other than 0x1FF; a comparison module 46, configured to compare the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container, and if a first predetermined number of consecutive comparison results are consistent, a synchronization state is entered, wherein the frame header indication overhead represents the number of byte blocks spaced between the first new client service frame header and the starting boundary of the service layer container.

[0143] In an optional embodiment, the expected frame header indication overhead value of the next service layer container is calculated by at least one of the following: the length of the customer service frame, the first number of customer service byte blocks used to carry the customer service byte blocks in the current service layer container, the second number of customer service byte blocks used to carry the customer service byte blocks in the next service layer container, and the frame header indication overhead of the current service layer container.

[0144] In an optional embodiment, the calculation module 44 includes: a first determination unit, configured to determine the third number of byte blocks for carrying customer service frame in the current service layer container based on the frame header indication overhead of the current service layer container, the first number and the length of the customer service frame; and a second determination unit, configured to determine the expected frame header indication overhead of the next service layer container based on the second number, the third number and the length of the customer service frame.

[0145] In an optional embodiment, the first determination unit includes: a first determination subunit, configured to determine a first remainder result of the length of the client service frame modulo the first quantity and the calculation result of the frame header indication overhead of the current service layer container; a second determination subunit, configured to determine the third quantity as the remainder result when the first remainder result is not 0; and a third determination subunit, configured to determine the third quantity as the length of the client service frame when the first remainder result is 0.

[0146] In an optional embodiment, the second determination unit includes: a fourth determination subunit, configured to determine the fourth number of client service frame byte blocks carried by the next service layer container based on the third number and the length of the client service frame; a fifth determination subunit, configured to determine that the expected frame header indication overhead of the next service layer container is the fourth number when the fourth number is less than or equal to the first difference between the second number and a predetermined value; and a sixth determination subunit, configured to determine that the expected frame header indication overhead of the next service layer container is 0x1FF when the fourth number is greater than the first difference between the second number and the predetermined value.

[0147] In an optional embodiment, the device further includes: a first determination module, configured to determine the fifth number of client service frame byte blocks carried by the next service layer container based on the expected frame header indication overhead of the next service layer container and the second number when the fourth number is less than or equal to the first difference between the second number and a predetermined value.

[0148] In an optional embodiment, the first determination module includes: a third determination unit, configured to determine a second remainder result of taking the remainder of the length of the customer service frame by taking the second difference between the second number and the expected frame header indication overhead of the next service layer container; and a fourth determination unit, configured to determine the fifth number based on the second remainder result.

[0149] In an optional embodiment, the fourth determination unit includes: a seventh determination subunit, configured to determine that the fifth quantity is the second remainder result when the second remainder result is not 0; and an eighth determination subunit, configured to determine that the fifth quantity is the length of the customer service frame when the second remainder result is 0.

[0150] In an optional embodiment, the device further includes: a second determination module, configured to determine the sixth number of customer service frame byte blocks carried by the next service layer container based on the third number and the second number when the fourth number is greater than the first difference between the second number and the predetermined value.

[0151] In an optional embodiment, the device further includes: a third determination module, configured to use the calculated number of customer service frame byte blocks carried by the next service layer container as the third number, and use the number of customer service byte blocks used to carry the subsequent service layer container as the second number to determine the expected frame header indication overhead of the subsequent service layer container.

[0152] Figure 5 is a second structural block diagram of the overhead processing device according to an embodiment of the present disclosure. As shown in Figure 5, the device includes: a second extraction module 52, configured to extract a first overhead and a second overhead from a target service layer container, wherein the first overhead and the second overhead are two adjacent overheads, and the first overhead and the second overhead are both used to indicate the reframe information of the service layer container; a synchronization module 54, configured to enter a synchronization state when it is determined that the values ​​of the first overhead and the second overhead are the same and the third overhead corresponding to the value of the first overhead is a value other than 0b111, or when the values ​​of the first overhead and the second overhead conform to a preset sequence and the third overhead corresponding to the value of the first overhead is 0b111.

[0153] In an optional embodiment, the preset sequence includes cycles from 0 to 10.

[0154] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0155] An embodiment of the present disclosure further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when run.

[0156] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0157] An embodiment of the present disclosure further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0158] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0159] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0160] Obviously, those skilled in the art should understand that the modules or steps of the present disclosure described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices, they can be implemented using program code executable by the computing device, and thus, they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present disclosure is not limited to any particular combination of hardware and software.

[0161] The foregoing description is merely a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, or improvements made within the principles of the present disclosure shall be included within the scope of protection of the present disclosure.

Claims

1. An overhead processing method, comprising: extracting an overhead indicated by a frame header from a current service layer container; calculating an expected overhead indicated by a frame header of a next service layer container based on the overhead indicated by the frame header of the current service layer container, wherein the overhead indicated by the frame header of the current service layer container is a value other than 0x1FF; comparing the expected overhead indicated by the frame header with the overhead indicated by the frame header extracted from the next service layer container. If the comparison results are consistent for a first predetermined number of consecutive times, enter a synchronization state, wherein the overhead indicated by the frame header represents the number of byte blocks between the start boundary of the service layer container and the first new customer service frame header.

2. The method according to claim 1, wherein The value of the expected overhead indicated by the frame header of the next service layer container is calculated from at least one of the following: the length of the customer service frame, the first number of byte blocks for carrying customer service bytes in the current service layer container, the second number of byte blocks for carrying customer service bytes in the next service layer container, and the overhead indicated by the frame header of the current service layer container.

3. The method according to claim 1, wherein, Calculating the expected overhead indicated by the frame header of the next service layer container based on the overhead indicated by the frame header of the current service layer container includes: determining a third number of byte blocks for carrying customer service frame bytes in the current service layer container based on the overhead indicated by the frame header of the current service layer container, the first number of byte blocks for carrying customer service bytes in the current service layer container, and the length of the customer service frame; determining the expected overhead indicated by the frame header of the next service layer container based on the second number of byte blocks for carrying customer service bytes in the next service layer container, the third number, and the length of the customer service frame.

4. The method according to claim 3, wherein Determining the third number of byte blocks for carrying customer service frame bytes in the current service layer container based on the overhead indicated by the frame header of the current service layer container, the first number, and the length of the customer service frame includes: determining a first remainder result obtained by taking the remainder of the calculation result of the first number and the overhead indicated by the frame header of the current service layer container with respect to the length of the customer service frame; when the first remainder result is not 0, determining the third number as the remainder result; when the first remainder result is 0, determining the third number as the length of the customer service frame.

5. The method according to claim 3, wherein, Determining the expected overhead indicated by the frame header of the next service layer container based on the second number, the third number, and the length of the customer service frame includes: determining a fourth number of byte blocks for carrying customer service frame bytes in the next service layer container based on the third number and the length of the customer service frame; when the fourth number is less than or equal to a first difference between the second number and a predetermined value, determining the expected overhead indicated by the frame header of the next service layer container as the fourth number; when the fourth number is greater than the first difference between the second number and the predetermined value, determining the expected overhead indicated by the frame header of the next service layer container as 0x1FF.

6. The method according to claim 5, wherein, The method further includes: When the fourth quantity is less than or equal to the first difference between the second quantity and a predetermined value, determine a fifth quantity of the next service layer container carrying a customer service frame byte block based on the expected frame header indication overhead of the next service layer container and the second quantity.

7. The method according to claim 6, wherein, Determining a fifth quantity of the next service layer container carrying a customer service frame byte block based on the expected frame header indication overhead of the next service layer container and the second quantity includes: Determining a second remainder result of taking the remainder of the length of the customer service frame by a second difference between the second quantity and the expected frame header indication overhead of the next service layer container; Determining the fifth quantity based on the second remainder result.

8. The method according to claim 7, wherein Determining the fifth quantity based on the second remainder result includes: When the second remainder result is not 0, determining the fifth quantity as the second remainder result; When the second remainder result is 0, determining the fifth quantity as the length of the customer service frame.

9. The method according to claim 5, wherein The method further includes: When the fourth quantity is greater than the first difference between the second quantity and the predetermined value, determine a sixth quantity of the customer service frame byte block carried by the next service layer container based on the third quantity and the second quantity.

10. The method according to claim 3, wherein, The method further includes: Taking the calculated quantity of the customer service frame byte block carried by the next service layer container as the third quantity, and taking the quantity used to carry the customer service byte block in the subsequent service layer container as the second quantity, and determining the expected frame header indication overhead of the subsequent service layer container.

11. An overhead processing method, including: Extracting a first overhead and a second overhead from a target service layer container, where the first overhead and the second overhead are two adjacent overheads, and both the first overhead and the second overhead are used to indicate the multiplexed frame information of the service layer container; When it is determined that the values of the first overhead and the second overhead are the same and the third overhead corresponding to the value of the first overhead is a value other than 0b111, or when the values of the first overhead and the second overhead conform to a preset sequence and the third overhead corresponding to the value of the first overhead is 0b111, enter the synchronization state.

12. The method according to claim 11, wherein, The preset sequence includes a cycle from 0 to 10.

13. An overhead processing device, including: A first extraction module configured to extract a frame header indication overhead from a current service layer container; A calculation module configured to calculate an expected frame header indication overhead of a next service layer container based on the frame header indication overhead of the current service layer container, where the frame header indication overhead of the current service layer container is a value other than 0x1FF; A comparison module configured to compare the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container. If the comparison results of a first predetermined number of consecutive times are the same, enter the synchronization state, where the frame header indication overhead represents the number of byte blocks between the start boundary of the service layer container and the first new customer service frame header.

14. An overhead processing device, including: A second extraction module, configured to extract a first overhead and a second overhead from a target service layer container, where the first overhead and the second overhead are two adjacent overheads, and both the first overhead and the second overhead are used to indicate the multiframe information of the service layer container; A synchronization module, configured to enter a synchronization state when it is determined that the values of the first overhead and the second overhead are the same and the third overhead corresponding to the value of the first overhead is a value other than 0b111, or when the values of the first overhead and the second overhead conform to a preset sequence and the third overhead corresponding to the value of the first overhead is 0b111.

15. A computer-readable storage medium storing a computer program therein, wherein, When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 10 are implemented, or the steps of the method described in any one of claims 11 to 12 are implemented.

16. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, where when the processor executes the computer program, the steps of the method described in any one of claims 1 to 10 are implemented, or the steps of the method described in any one of claims 11 to 12 are implemented.

Images