Overhead processing method and device, storage medium and electronic device

Abstract

The embodiment of the invention provides an overhead processing method and device, a storage medium and an electronic device, and the method comprises the steps: extracting frame header indication overhead from a current service layer container; the expected frame header indication overhead of a next service layer container is calculated based on the frame header indication overhead of the current service layer container, and the frame header indication overhead is a value except 0x1FF; and comparing the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container, and if a first preset number of consecutive comparison results are consistent, entering a synchronization state, the frame header indication overhead represents the number of byte blocks at an interval between the first new customer service frame header and the starting boundary of the service layer container. Through application of the method and the device, the problem of overhead error caused by transmission error in related technologies is solved, so that the accuracy of the determined overhead is improved, and the effect that the boundary structure of the customer service can be accurately identified is achieved.

Description

Technical Field

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

[0002] fgODUflex (flexible OTN Digital Unit) is a container in the optical transport network used to carry small granular services. VC-n (Virtual Container-n) realizes efficient carrying through fgODUflex. VC-n has a fixed frame length. When demapping the client service from fgODUflex, it is necessary to first identify the boundary of the VC-n frame structure and then perform service parsing. There is no overhead for framing in VC-n. Therefore, dedicated overhead is defined in fgODUflex to indicate the position of the VC-n frame header in fgODUflex. During the transmission process, bit errors will cause errors in the overhead, resulting in the inability to correctly identify the structure boundary of VC-n, and thus the normal parsing of the client service cannot be completed. Identifying these overhead errors is a problem that needs to be solved. Summary of the Invention

[0003] The embodiments of the present invention 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.

[0004] According to an embodiment of the present invention, an overhead processing method is provided, including: extracting frame header indication overhead from a current service layer container; calculating 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; comparing 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 a continuous first predetermined number of times, enter a synchronization state, where the frame header indication overhead represents the number of byte blocks between the first new client service frame header and the start boundary of the service layer container.

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

[0006] 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 a third quantity for carrying the customer service frame byte block in the current service layer container based on the frame header indication overhead of the current service layer container, the first quantity, and the length of the customer service frame; determining the expected frame header indication overhead of the next service layer container based on the second quantity, the third quantity, and the length of the customer service frame.

[0007] In an exemplary embodiment, determining a third quantity for carrying the customer service frame byte block in the current service layer container based on the frame header indication overhead of the current service layer container, the first quantity, and the length of the customer service frame includes: determining a first remainder result of taking the remainder of the calculation result of the first quantity and the frame header indication overhead of the current service layer container with respect to the length of the customer service frame; in the case where the first remainder result is not 0, determining the third quantity as the remainder result; in the case where the first remainder result is 0, determining the third quantity as the length of the customer service frame.

[0008] In an exemplary embodiment, determining the expected frame header indication overhead of the next service layer container based on the second quantity, the third quantity, and the length of the customer service frame includes: determining a fourth quantity for the next service layer container to carry the customer service frame byte block based on the third quantity and the length of the customer service frame; in the case where the fourth quantity is less than or equal to the first difference between the second quantity and a predetermined value, determining the expected frame header indication overhead of the next service layer container as the fourth quantity; in the case where the fourth quantity is greater than the first difference between the second quantity and the predetermined value, determining the expected frame header indication overhead of the next service layer container as 0x1FF.

[0009] In an exemplary embodiment, the method further includes: in the case where the fourth quantity is less than or equal to the first difference between the second quantity and a predetermined value, determining a fifth quantity for the next service layer container to carry the customer service frame byte block based on the expected frame header indication overhead of the next service layer container and the second quantity.

[0010] In an exemplary embodiment, determining a fifth quantity for the next service layer container to carry the 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 second difference between the second quantity and the expected frame header indication overhead of the next service layer container with respect to the length of the customer service frame; determining the fifth quantity based on the second remainder result.

[0011] 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 client service frame.

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

[0013] In an exemplary embodiment, the method further includes: taking the calculated quantity of the client service frame byte block carried by the next service layer container as the third quantity, and taking the quantity of the subsequent service layer container for carrying the client service byte block as the second quantity, and determining the expected frame header indication overhead of the subsequent service layer container.

[0014] According to another embodiment of the present invention, there is provided 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; entering 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.

[0015] In an exemplary embodiment, the preset sequence includes a cycle from 0 to 10.

[0016] According to another embodiment of the present invention, there is provided an overhead processing apparatus, 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, and enter a synchronization state if the comparison results of a first predetermined number of consecutive times are consistent, where the frame header indication overhead represents the number of byte blocks between the first new client service frame header and the start boundary of the service layer container.

[0017] According to another embodiment of the present invention, there is provided 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.

[0018] According to still another embodiment of the present invention, there is also provided a computer-readable storage medium, in which a computer program is stored, and the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0019] According to still another embodiment of the present invention, there is also provided an electronic device, including a memory and a processor, where a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0020] Through the present invention, 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 that layer, accurate identification of overhead errors can be achieved. Therefore, the problem of overhead errors caused by transmission errors in the related art can be solved, and the accuracy of the determined overhead can be improved, so that the boundary structure of the customer service can be accurately identified. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a hardware structure block diagram of a mobile terminal of an overhead processing method according to an embodiment of the present invention;

[0022] Figure 2 is the flow of an overhead processing method according to an embodiment of the present invention Figure 1 ;

[0023] Figure 3 is the flow of an overhead processing method according to an embodiment of the present invention Figure 2 ;

[0024] Figure 4 is the structure block of an overhead processing device according to an embodiment of the present invention Figure 1 ;

[0025] Figure 5 is the structure block of an overhead processing device according to an embodiment of the present invention Figure 2 。 DETAILED DESCRIPTION OF THE EMBODIMENTS

[0026] Embodiments of the present invention will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

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

[0028] First, the related technologies involved in the present invention will be described:

[0029] OTN (Optical Transport Network) is mainly used to carry large granular services above 1G, which will cause bandwidth waste for carrying customer services below 1G. For example, carrying a 10M service in a 1.25G ODU0 (Optical channel Data Unit 0) will result in a large amount of bandwidth waste. In order to better support the carrying of customer services below 1G, the international standard organization is discussing the fgOTN (flexible grid Optical Transport Network) technology. The fgOTN technology is an extension of the existing OTN technology and can efficiently support customer services below 1G. The related technology discussions have converged. During the discussion of the fgOTN technology, dedicated overheads have been defined for carrying customer services below 1G. How to detect these overheads and the subsequent processing after an alarm is generated will be a key point in the discussion of the fgOTN technology.

[0030] The fgODUflex is a container used to carry small granular services in the optical transport network. Low-speed customer services such as E1 (E-carrier Level 1, E1 circuit), VC-n, FE (Fast Ethernet), STM-1 (Synchronous Transport Module level-1), etc. can be efficiently carried through the fgODUflex. Customer services all have relevant structural characteristics. Services such as VC-n and STM-1 have fixed frame lengths, while Ethernet services are composed of 66b. Whether it is the frame structure or the 66b structure, when demapping the customer service from the fgODUflex, it is necessary to identify the boundary of the structure before the service can be parsed. The STM-1 service has a frame header indication signal. After demapping the STM-1 from the fgODUflex, the identification of the STM-1 frame boundary can be completed based on the framing process of the STM-1. However, the VC-n service has no overhead for framing. In the current discussion, special overhead is defined in the fgODUflex to indicate the position of the VC-n frame header in the fgODUflex. For Ethernet services based on 66b, although the IEEE802.3 standardizes the function of positioning the 66b boundary, the Ethernet services carried by the fgODUflex have relatively low speeds. If the 66b boundary is positioned according to the IEEE802.3 definition method, it will cause a relatively large processing delay. Therefore, overhead is also defined in the fgOTN technology to identify the 66b boundary and accelerate the processing speed of boundary identification. During the transmission process, these overheads may be affected by bit errors, and the incorrect overhead will result in the inability to correctly identify the structural boundary of the customer service, thus preventing the normal parsing of the customer service. Identifying these incorrect overheads is a problem that needs to be solved.

[0031] In view of the above problems in the related art, corresponding solutions are proposed in the embodiments of the present invention. The present invention will be described below in conjunction with the embodiments:

[0032] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 is a hardware structure block diagram of a mobile terminal according to the overhead processing method of the embodiments of the present invention. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1 only one is shown in Figure 1 ) 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 for storing data. Among them, the above mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand,Figure 1 The structure shown is only schematic and does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal may further include more or fewer components than those shown in Figure 1 or have a different configuration from that shown in Figure 1 .

[0033] The memory 104 can be used 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 embodiments of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implements the above 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 memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories can be connected to the mobile terminal through a network. Examples of the above network include but are not limited to the Internet, enterprise intranets, local area networks, mobile communication networks, and combinations thereof.

[0034] The transmission device 106 is used to receive or send data via a network. Specific examples of the above network may include a wireless network provided by a communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (abbreviated as NIC for Network Interface Controller), which can be connected to other network devices through a base station and thus communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (abbreviated as RF) module, which is used to communicate with the Internet wirelessly.

[0035] In this embodiment, an overhead processing method is provided. Figure 2 is a flow chart of the overhead processing method according to the embodiments of the present invention. Figure 1 , as Figure 2 shown, the flow includes the following steps:

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

[0037] 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, where the frame header indication overhead of the current service layer container is a value other than 0x1FF;

[0038] 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 of a consecutive first predetermined number are consistent, 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 client service frame header.

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

[0040] On the sending side, map the VC-n service to the payload area of fgODUflex in a manner including, but not limited to, GMP (Group Management Protocol). The mapping process includes, but is not limited to: processing two rows of the fgODUflex frame as a mapping payload area. A VC-n client service frame may be mapped to one mapping payload area or span two or more mapping payload areas. When the mapping of the VC-n client service in the previous mapping payload area is completed, the 16-byte data volume X transferred by a certain VC-n frame in one or more previous mapping areas and the 16-byte data volume Y to be transferred in the current one or more mapping payload areas can be known. The 16-byte data volume of client service that each mapping payload area can carry includes, but is not limited to, C128 (Code 128). If Y is less than or equal to C128 - 1, it means that the frame header of the next VC-n service frame will appear in the current mapping payload area. At this time, use the Y value as the content of the CFS (Client Frame Start) overhead (i.e., the frame header indication overhead of the current service layer container mentioned above). Since GMP mapping will increase the number of 16-byte padding blocks, the position of the next VC-n frame header in the mapping payload area is not necessarily Y + 1. If Y is greater than C128 - 1, it means that the frame header of the next VC-n client service will not appear in the current mapping payload area. Fill the CFS with a fixed value of 0x1FF. The byte blocks include data blocks and padding blocks.

[0041] At the receiving side, according to the mapping overhead of GMP, a 16-byte data block and a 16-byte padding block used to carry the VC-n client service are calculated in a manner including but not limited to the sigma-delta algorithm in the mapped payload area. 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 according to the CFS (Client Frame Start) overhead in the fgODUflex frame. However, during the service transmission process, it will be affected by bit errors, which will cause the CFS overhead to be incorrect, thus affecting the identification of the VC-n client service frame boundary. It is necessary to detect and process the CFS overhead. The CFS overhead detection and processing has two states, one is the synchronous state and the other is the out-of-sync state. The current CFS overhead value is extracted from the overhead of the fgODUflex frame. If the value of CFS is 0x1FF, the next CFS overhead value is extracted until a non-0x1FF CFS overhead value Y(i) is obtained, and the next CFS overhead expected value E(i + 1) is predicted based on this CFS overhead value. The next CFS overhead expected value is determined by the current CFS overhead value Y(i), the frame length L of the VC-n client service in 16-byte units, and the number C128(i) of 16-byte data blocks used to carry the VC-n client service in the current mapped payload area and the number C128(i + 1) of 16-byte data blocks used to carry the VC-n client service in the next mapped payload area.

[0042] The VC-n service has different frame lengths according to different service types. 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 invention, preferably, the frame length of the VC-n service is 144 bytes (i.e., 9 16-byte units). For the same type of VC-n service, there may also be a need to transmit v cascaded VC-ns. The frame length of the cascaded VC-n client service is also enlarged by v times.

[0043] 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 includes but is not limited to a 16-byte block. The first predetermined number includes 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 and processing.

[0044] Among them, the execution entity of the above steps can be a base station, a terminal, etc., or a specific network element or node on the network side, or other devices with similar processing capabilities, but not limited thereto.

[0045] 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 that layer, accurate identification of overhead errors can be achieved. Therefore, the problem of overhead errors caused by transmission errors in the related art can be solved, and furthermore, the accuracy of the determined overhead is improved, so that the boundary structure of the customer service can be accurately identified.

[0046] In an alternative embodiment, the expected frame header indication overhead value of the next service layer container is calculated from at least one of the following: the length of the customer service frame, the first quantity of the customer service byte blocks carried in the current service layer container, the second quantity of the customer service byte blocks carried in the next service layer container, and the frame header indication overhead of the current service layer container.

[0047] 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, etc., but not limited thereto. Exemplarily, the length of the customer service frame is in units of 16 bytes, and the length of the customer service frame includes but is not limited to: 144 bytes, that is, 9 16-byte units. In addition, the lengths of multiple customer service frames mapped from the customer service are generally the same.

[0048] In an alternative 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 a third quantity of the customer service frame byte blocks carried in the current service layer container based on the frame header indication overhead of the current service layer container, the first quantity, and the length of the customer service frame; determining the expected frame header indication overhead of the next service layer container based on the second quantity, the third quantity, and the length of the customer service frame.

[0049] In the above steps, the third quantity is the number of byte blocks remaining after the current service layer container has completed the transfer of one or more complete customer service frames and is insufficient to transfer a complete customer service frame, that is, the number of partial byte blocks carrying a complete customer service frame.

[0050] In an optional embodiment, determining the third quantity for carrying the customer service frame byte block in the current service layer container based on the frame header indication overhead of the current service layer container, the first quantity, and the length of the customer service frame includes: determining a first remainder result of taking the remainder of the calculation result of the first quantity and the frame header indication overhead of the current service layer container with respect to the length of the customer service frame; in the case where the first remainder result is not 0, determining the third quantity as the remainder result; and in the case where the first remainder result is 0, determining the third quantity as the length of the customer service frame.

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

[0052] The following uses embodiments to make an overall description of the foregoing method:

[0053] Embodiment 1:

[0054] First, explain the relevant parameters in the embodiment: 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-byte quantities for carrying the VC-n service in the current i-th mapped payload area (i.e., the first quantity mentioned above), and X(i) is used to represent the number of 16-byte quantities of the VC-n customer service frame carried in the current i-th mapped payload area (i.e., the third quantity mentioned above), where i is an integer greater than zero.

[0055] Based on the current CFS overhead value Y(i) that is not 0x1FF, the frame length L of the VC-n customer service (in units of 16 bytes), and the number of 16-byte quantities C128(i) for carrying the VC-n service in the current i-th mapped payload area, determine the number of 16-byte quantities X(i) of the VC-n customer service frame carried in the current i-th mapped payload area.

[0056] When the remaining 16 - byte quantity C128(i) - Y(i) in the i - th mapped payload area for carrying the VC - n data volume is greater than L, that is, after the previous complete TU - 12 frame is carried in the i - th mapped payload area, the remaining 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 remainder of (C128(i) - Y(i)) divided by the VC - n client service frame length L. If the remainder is not 0, then X(i)=(C128(i) - Y(i)) mod L, otherwise X(i)=L.

[0057] When the remaining 16 - byte quantity C128(i) - Y(i) in the i - th mapped payload area for carrying the VC - n data volume is less than or equal to L, that is, after the previous complete TU - 12 frame is carried in the i - th mapped payload area, the remaining 16 - byte quantity is not enough to carry one VC - n client service frame or just enough to carry one VC - n client service frame. After mapping the VC - n client service to the current i - th mapped payload area, the 16 - byte quantity X(i) of a complete VC - n client service frame carried by the i - th mapped payload area is X(i)=C128(i) - Y(i). The value of X(i) is greater than or equal to 1 and less than or equal to L.

[0058] The above steps are described below in combination with formulas:

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

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

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

[0062] Otherwise X(i)=L;

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

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

[0065] Embodiment 2:

[0066] First, the relevant parameters in the embodiments are described as follows: 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 client service, C128(i) is used to represent the number of 16-byte quantities for carrying VC-n services in the current i-th mapped payload area (i.e., the first quantity mentioned above), and X(i) is used to represent the number of 16-byte quantities of the VC-n client service frames carried in the current i-th mapped payload area (i.e., the third quantity mentioned above), where i is an integer greater than zero.

[0067] According to the current CFS overhead value Y(i) that is not 0x1FF, the frame length L of the VC-n client service (in units of 16 bytes), and the number of 16-byte quantities C128(i) for carrying VC-n services in the current i-th mapped payload area, determine the number of 16-byte quantities X(i) of the VC-n client service frames carried in the current i-th mapped payload area.

[0068] The number of 16-byte quantities 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 remainder of (C128(i) - Y(i)) divided by the frame length L of the VC-n client service. If the remainder result is not 0, then X(i) = (C128(i) - Y(i)) mod L, otherwise X(i) = L.

[0069] The above steps are described below in combination with formulas:

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

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

[0072] Otherwise X(i) = L

[0073] In an alternative embodiment, determining the expected frame header indication overhead of the next service layer container based on the second quantity, the third quantity, and the length of the client service frame includes: determining a fourth quantity of the byte blocks of the client service frames carried by the next service layer container based on the third quantity and the length of the client service frame; in the case where the fourth quantity is less than or equal to the first difference between the second quantity and a predetermined value, determining the expected frame header indication overhead of the next service layer container as the fourth quantity; in the case where the fourth quantity is greater than the first difference between the second quantity and the predetermined value, determining the expected frame header indication overhead of the next service layer container as 0x1FF.

[0074] In an alternative embodiment, the method further includes: when the fourth quantity is less than or equal to a first difference between the second quantity and a predetermined value, determining a fifth quantity of the next service layer container for carrying a customer service frame byte block based on an expected frame header indication overhead of the next service layer container and the second quantity.

[0075] In the above step, the fifth quantity is the number of byte blocks remaining after the next service layer container has completed the transfer of the current and one or more new complete customer service frames, and is insufficient to transfer one complete customer service frame, that is, the number of partial byte blocks carrying one complete customer service frame.

[0076] In an alternative embodiment, determining the fifth quantity of the next service layer container for 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 obtained by taking the remainder of a second difference between the second quantity and the expected frame header indication overhead of the next service layer container with respect to the length of the customer service frame; and determining the fifth quantity based on the second remainder result.

[0077] In an alternative 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; and when the second remainder result is 0, determining the fifth quantity as the length of the customer service frame.

[0078] In an alternative embodiment, the method further includes: when the fourth quantity is greater than the first difference between the second quantity and the predetermined value, determining 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.

[0079] The following provides an overall description of the foregoing method in combination with specific embodiments:

[0080] Embodiment III:

[0081] First, the relevant parameters in the embodiments are described as follows: 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 client service, C128(i) is used to represent the number of 16-byte units for carrying VC-n services in the current i-th mapped payload area (i.e., the first quantity mentioned above), C128(i + 1) is used to represent the number of 16-byte units for carrying VC-n services in the current (i + 1)-th mapped payload area (i.e., the second quantity mentioned above), X(i) is used to represent the number of 16-byte units of the VC-n client service frames carried in the current i-th mapped payload area (i.e., the third quantity mentioned above), and E(i + 1) is used to represent the CFS expected value E(i + 1) corresponding to the (i + 1)-th mapped payload area (i.e., the expected frame header indication overhead mentioned above), where i is an integer greater than zero.

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

[0083] 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 will appear in the (i + 1)-th mapped payload area, then E(i + 1) = L – X(i); the value of the number of 16-byte units X(i + 1) of the last complete VC-n client service frame carried in the (i + 1)-th mapped payload area is determined by the number of 16-byte units C128(i + 1) for carrying VC-n services and E(i + 1) in the (i + 1)-th mapped payload area. If the remainder of (C128(i + 1) - E(i + 1)) divided by the VC-n client service frame length L is not 0, then X(i + 1) = (C128(i + 1) - E(i + 1)) mod L, otherwise X(i + 1) = L.

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

[0085] The above steps are described below in combination with formulas:

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

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

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

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

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

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

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

[0093] Example 4:

[0094] First, the relevant parameters in the example are described: 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 - byte quantities used to carry VC - n services in the current i - th mapped payload area (i.e., the first quantity mentioned above), C128(i + 1) is used to represent the number of 16 - byte quantities used to carry VC - n services in the current (i + 1) - th mapped payload area (i.e., the second quantity mentioned above), X(i) is used to represent the number of 16 - byte quantities of the VC - n customer service frames carried in the current i - th mapped payload area (i.e., the third quantity mentioned above), and E(i + 1) is used to represent the CFS expected value E(i + 1) corresponding to the (i + 1) - th mapped payload area (i.e., the expected frame header indication overhead mentioned above), where i is an integer greater than zero.

[0095] According to the X(i) calculated in the above - mentioned example and the length L of the VC - n customer service frame, determine the CFS expected value E(i + 1) and X(i + 1) corresponding to the (i + 1) - th mapped payload area.

[0096] When (L – X(i)) is less than or equal to (C128(i + 1) - 1), that is, the frame header of the customer service VC - n will appear in the (i + 1) - th mapped payload area, then E(i + 1) = L – X(i); the value of the number of 16 - byte quantities X(i + 1) of the last complete VC - n customer service frame carried in the (i + 1) - th mapped payload area is determined by the number of 16 - byte quantities C128(i + 1) used to carry VC - n services in the (i + 1) - th mapped payload area and E(i + 1). If the remainder of (C128(i + 1) - E(i + 1)) divided by the VC - n customer service frame length L is not 0, then X(i + 1) = (C128(i + 1) - E(i + 1)) mod L, otherwise X(i + 1) = L.

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

[0098] The above steps are described below in combination with formulas:

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

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

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

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

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

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

[0105] Then E(i + 1) = 0x1FF, X(i + 1) =

C128(i) - Y(i)

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

[0107] In the above embodiments, by repeatedly executing the steps in the foregoing embodiments, the expected overhead values (i.e., the aforementioned CFS expected values) in all subsequent service layer containers can be calculated. Specifically, this can be achieved by setting i in the above embodiments to i + 1. In the out-of-step state, starting from the first non-0x1FF CFS overhead value received, if the CFS overhead values received continuously for N times are the same as the expected value, it enters the synchronization state. In the synchronization state, when the calculated CFS expected value is inconsistent with the extracted CFS overhead value, 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 this CFS expected value. In the synchronization state, when the CFS overhead values received continuously for M times are different from the expected value, it enters the out-of-step state and generates a CFS loss alarm, and the CFS loss alarm triggers the generation of a maintenance signal for the VC-n client service. N and M are integers greater than or equal to 1.

[0108] The following is a general description of the solution of the present invention in combination with specific embodiments: Specific Embodiment 1:

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

[0111] Step 1, at the source node, parse out the TU-12 from the STM interface. Among them, the multiplex frame of the TU-12 is 144 bytes. Map the TU-12 to the 2-line mapped payload area of the fgODUflex frame in the GMP manner and insert the CFS overhead. The multiplex frame length of the TU-12 is L = 9 16-byte blocks, and the number of 16-byte blocks used to carry the TU-12 frame in the 2-line mapped payload area of the fgODUflex is 105 and 106. Therefore, the frame header of the TU-12 will appear in each 2-line mapped payload area of the fgODUflex, that is, the CFS value will not be 0x1FF. The default CFS overhead is in the out-of-step state, and the synchronization process of the CFS overhead is performed.

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

[0113] Step 3, the remaining number of 16-byte blocks in the 2-line mapped payload area of the i-th fgODUflex frame that can be used to carry TU-12 frames is C128(i) - Y(i) = 105 - 6 = 99 16-byte blocks. The length L of the TU-12 frame is 9 16-byte blocks, and C128(i) - Y(i) > L, that is, 99 16-byte blocks can exactly carry 11 complete TU-12 frames. Since (C128(i) - Y(i)) mod L = (105 - 6) mod 9 = 0, the number of 16-byte blocks X(i) in the 2-line mapped payload area of the i-th fgODUflex frame used to carry the last complete TU-12 frame is X(i) = L = 9, indicating that a complete TU-12 frame is transmitted.

[0114] Step 4, extract the number of 16-byte data blocks C128(i + 1) = 106 in the 2-line mapped payload area of the (i + 1)-th fgODUflex frame corresponding to the GMP overhead in the 2-line mapped payload area of the i-th fgODUflex frame. According to the number X(i) = 9 of the last complete TU-12 frame carried in the 2-line mapped payload area of the i-th fgODUflex frame in Step 3 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 expected CFS overhead value E(i + 1) corresponding to the 2-line mapped payload area of the (i + 1)-th fgODUflex frame is E(i + 1) = L - X(i) = 9 - 9 = 0.

[0115] Step 5, the remaining number of 16-byte blocks in the 2-line mapped payload area of the (i + 1)-th fgODUflex frame that can be used to carry TU-12 frames is C128(i + 1) - E(i + 1) = 106 - 0 = 106 16-byte blocks. C128(i + 1) - E(i + 1) > L, that is, 106 16-byte blocks can carry 11 complete TU-12 frames plus the first 7 bytes of a complete TU-12 frame. That is, the number of 16-byte blocks X(i + 1) in the 2-line mapped payload area of the (i + 1)-th fgODUflex frame used to carry the last complete TU-12 frame is X(i + 1) = (C128(i + 1) - E(i + 1)) mod L = (106 - 0) mod 9 = 7.

[0116] Step 6, change i to i + 1, and repeat Steps 4 and 5, and the expected CFS overhead values for all subsequent fgODUflex frames such as the (i + 2)-th and (i + 3)-th can be calculated.

[0117] Step 7, if the CFS overhead value and the CFS expected value received continuously twice are the same, enter the synchronization state. Use the CFS value to identify the TU-12 frame header, and continuously compare the CFS overhead value and the CFS expected value.

[0118] Step 8: In the synchronized state, if the CFS overhead values received continuously for 5 times are different from the CFS expected values, enter the out-of-sync state and generate a CFS loss alarm. This alarm triggers the use of a maintenance signal to replace the normal TU-12 signal. Resume CFS synchronization processing from Step 2 until the synchronized state is entered. Specific Embodiment 2:

[0120] Step 1: At the source node, parse 60 TU-12s from the STM interface, interleave the 60 TU-12s into a data stream by bytes. The multiplex frame length of TU-12 is 144 bytes. Map the interleaved TU-12 data stream into the 2-row mapped payload area of the fgODUflex frame in the GMP manner and insert the CFS overhead. The multiplex frame length of TU-12 is 9 * 16 bytes, and the length L of the 60xTU-12 data frame after interleaving is 9 * 60 = 540 * 16 bytes. The number of 16-byte blocks used to carry the interleaved 60xTU-12 data frame in the 2-row mapped payload area of fgODUflex is 453 or 454. There is a case where the 2-row mapped payload area of a certain fgODUflex frame does not have the frame header of the interleaved 60xTU-12 data frame, that is, the CFS value will be 0x1FF; the default CFS overhead is in the out-of-sync state, and synchronization processing of the CFS overhead is performed.

[0121] 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 number of 16-byte data blocks C128(i) = 453 used to carry the interleaved 60xTU-12 data frame in the 2-row mapped payload area of the i-th fgODUflex frame is carried at the GMP overhead position corresponding to the 2-row mapped payload area of the (i - 1)-th fgODUflex frame.

[0122] Step 3, the remaining number of 16-byte units in the 2-line mapped payload area of the i-th fgODUflex frame that can be used to carry the interleaved 60xTU-12 data frames is C128(i) - Y(i) = 453 - 450 = 3 16-byte units. The length L of the interleaved 60xTU-12 data frame is 540 16-byte units. Since C128(i) - Y(i) < L, that is, the remaining 3 16-byte units are not enough to carry a complete interleaved 60xTU-12 data frame. The number of 16-byte units X(i) in the 2-line mapped payload area of the i-th fgODUflex frame used to carry the last complete interleaved 60xTU-12 data frame is X(i) = C128(i) - Y(i) = 453 - 450 = 3, indicating that the first 3 16-byte units of the last complete interleaved 60xTU-12 data frame are carried.

[0123] Step 4, in the GMP overhead corresponding to the 2-line mapped payload area of the i-th fgODUflex frame, the number of 16-byte data blocks C128(i + 1) = 454 in the 2-line mapped payload area of the (i + 1)-th fgODUflex frame used to carry the interleaved 60xTU-12 data frames is extracted. According to the number X(i) = 3 of the last complete interleaved 60xTU-12 data frame carried in the 2-line mapped payload area of the i-th fgODUflex frame in Step 3 and the length L (540 16-byte units) of the interleaved 60xTU-12 data frame, L - X(i) = 540 - 3 = 537 > C128(i + 1) - 1 = 454 - 1 = 453, which means that the 2-line mapped payload area of the (i + 1)-th fgODUflex frame is not enough to carry the remaining 537 bytes of the last complete interleaved 60xTU-12 data frame of the i-th frame, that is, the frame header of the next interleaved 60xTU-12 data frame will not appear in the 2-line mapped payload area of the (i + 1)-th fgODUflex frame. Therefore, the CFS expected overhead value E(i + 1) corresponding to the 2-line mapped payload area of the (i + 1)-th fgODUflex frame is 0x1FF.

[0124] Step 5, 454 16-byte units in the 2-line mapped payload area of the (i + 1)-th fgODUflex frame can be used to carry the interleaved 60xTU-12 data frames. That is, after the mapping of the interleaved 60xTU-12 data frame to the 2-line mapped payload area of the (i + 1)-th fgODUflex frame is completed, the number of 16-byte units X(i + 1) in the 2-line mapped payload area of the fgODUflex frame for a complete interleaved 60xTU-12 data frame is X(i + 1) = C128(i) - Y(i) + C128(i + 1) = 453 - 450 + 454 = 457.

[0125] Step 6: Change i to i + 1, and repeat Steps 4 and 5 to calculate the expected CFS overhead values for all subsequent ones such as the (i + 2)-th and the (i + 3)-th ones.

[0126] Step 7: If the CFS overhead values and the CFS expected values received continuously twice are the same, enter the synchronization state. Use the CFS value to identify the frame header of the 60xTU-12 data frame after interleaving, and continuously compare the CFS overhead value with the CFS expected value.

[0127] Step 8: In the synchronization state, if the CFS overhead values and the CFS expected values received continuously five times are different, enter the out-of-synchronization state and generate a CFS loss alarm. This alarm triggers the use of a maintenance signal to replace the normal interleaved 60xTU-12 data frame signal. Resume the CFS synchronization process from Step 2 until entering the synchronization state.

[0128] Figure 3 is the flowchart of the overhead processing method according to an embodiment of the present invention Figure 2 , as Figure 3 shown, this flowchart includes the following steps:

[0129] Step S302: Extract a first overhead and a second overhead from the 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;

[0130] Step S304: 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.

[0131] 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:

[0132] On the sending side, Ethernet services are mapped into the payload area of fgODUflex in the manner of IMP (Interface Mapping Processor). The Ethernet service has a 66b structure. The first bit of the first 66b code block in the Ethernet client service flow is mapped to the first bit of the payload area of the first fgODUflex frame, and the last bit of the 20224th 66b code block is mapped to the last bit of the payload area of the 11th fgODUflex frame. This process repeats in sequence to complete the entire mapping process. The OMFI (Optical Multiplex Frame Identifier) overhead is used for cyclic counting of 11 fgODUflex frames. 8 OMFI overheads are defined in each fgODUflex frame, and the values of these OMFI overheads are the same.

[0133] On the receiving side, the Ethernet client service is extracted from the fgODUflex payload area, and the 66b boundary of the Ethernet service is identified based on the OMFI overhead in the fgODUflex frame. However, during service transmission, it is affected by bit errors, which can cause the OMFI overhead to be incorrect, thus affecting the identification of the 66b boundary of the Ethernet service. It is necessary to detect and process the OMFI overhead. There are two states for the OMFI overhead detection and processing, one is the synchronization state and the other is the out-of-synchronization state.

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

[0135] In the synchronous state, when it is detected that the adjacent two OMFI overhead values are different when the HRN corresponding to the first OMFI overhead value is not 0b111, or the adjacent two OMFI overhead values do not conform to the preset sequence when the HRN corresponding to the first OMFI overhead value is 0b111, these two situations are abnormal situations. When abnormal situations occur continuously for Z times, it enters the out-of-sync state. After the out-of-sync state lasts for a period of time, an OMFI loss alarm is generated, and the OMFI loss alarm triggers the generation of 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 OMFI out-of-sync.

[0136] Through the above steps, since the adjacent overheads in the same service layer are compared, it is possible to accurately identify the overhead error. Therefore, the problem of overhead error caused by transmission error in the related art can be solved, and further the accuracy of the determined overhead is improved, so that the boundary structure of the client service can be accurately identified.

[0137] In an optional embodiment, the preset sequence includes a cycle from 0 to 10.

[0138] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present invention, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc), and includes several instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in various embodiments of the present invention.

[0139] In this embodiment, an overhead processing device is also provided. The device is used to implement the above embodiments and preferred embodiments, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that can implement a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0140] Figure 4 is the structural block diagram of the overhead processing device according to the embodiment of the present invention Figure 1 , as Figure 4As shown, the device includes: a first extraction module 42 for extracting a frame header indication overhead from the current service layer container; a calculation module 44 for calculating an 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; a comparison module 46 for 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 the comparison results of a first predetermined number of consecutive times are consistent, wherein 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.

[0141] In an optional embodiment, the value of the expected frame header indication overhead 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 the customer service in the current service layer container, the second number of byte blocks for carrying the customer service in the next service layer container, and the frame header indication overhead of the current service layer container.

[0142] In an optional embodiment, the calculation module 44 includes: a first determination unit for determining a third number of byte blocks for carrying the 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; a second determination unit for 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 customer service frame.

[0143] In an optional embodiment, the first determination unit includes: a first determination subunit for determining a first remainder result obtained by taking the remainder of the calculation result of the first number and the frame header indication overhead of the current service layer container with respect to the length of the customer service frame; a second determination subunit for determining the third number as the remainder result when the first remainder result is not 0; a third determination subunit for determining the third number as the length of the customer service frame when the first remainder result is 0.

[0144] In an optional embodiment, the second determination unit includes: a fourth determination subunit for determining a fourth number of byte blocks for carrying the customer service frame in the next service layer container based on the third number and the length of the customer service frame; a fifth determination subunit for determining the expected frame header indication overhead of the next service layer container as the fourth number when the fourth number is less than or equal to a first difference between the second number and a predetermined value; a sixth determination subunit for determining the expected frame header indication overhead of the next service layer container as 0x1FF when the fourth number is greater than the first difference between the second number and the predetermined value.

[0145] In an optional embodiment, the apparatus further includes: a first determination module, configured to, when the fourth quantity is less than or equal to a first difference between the second quantity and a predetermined value, determine a fifth quantity of the next service layer container for carrying a customer service frame byte block based on an expected frame header indication overhead of the next service layer container and the second quantity.

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

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

[0148] In an optional embodiment, the apparatus further includes: a second determination module, configured to, 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.

[0149] In an optional embodiment, the apparatus further includes: a third determination module, configured to use the calculated quantity of the customer service frame byte block carried by the next service layer container as the third quantity, and use the quantity for carrying the customer service byte block in a subsequent service layer container as the second quantity, and determine an expected frame header indication overhead of the subsequent service layer container.

[0150] Figure 5 is a structural block diagram of an overhead processing apparatus according to an embodiment of the present invention Figure 2 , as Figure 5 shown, the apparatus includes: a second extraction module 52, 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 a multiplexed frame information of the service layer container; a synchronization module 54, configured to enter a synchronization state when it is determined that values of the first overhead and the second overhead are the same and a 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.

[0151] In an alternative embodiment, the preset sequence includes a cycle from 0 to 10.

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

[0153] An embodiment of the present invention also provides a computer-readable storage medium, in which a computer program is stored. Wherein, the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0154] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical discs and other various media that can store computer programs.

[0155] An embodiment of the present invention also provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

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

[0157] The specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be repeated here.

[0158] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present invention can be implemented by a general-purpose computing device. They can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. 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 executed in a different order than here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. In this way, the present invention is not limited to any specific combination of hardware and software.

[0159] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for handling overheads, characterized in that, Including: Extracting the frame header indication overhead from the current service layer container; 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, where 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. If the comparison results are consistent for a continuous first predetermined number of times, enter the synchronization state, where the frame header indication overhead represents the number of byte blocks between the first new customer service frame header and the start boundary of the service layer container.

2. The method according to claim 1, wherein The value of the expected frame header indication overhead 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 in the current service layer container, the second number of byte blocks for carrying customer service in the next service layer container, and the frame header indication overhead of the current service layer container.

3. The method according to claim 1, characterized in that, 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 a third number of byte blocks for carrying the 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 of byte blocks for carrying customer service in the current service layer container, and the length of the customer service frame; Determining the expected frame header indication overhead of the next service layer container based on the second number of byte blocks for carrying customer service in the next service layer container, the third number, and the length of the customer service frame.

4. The method according to claim 3, characterized in that, Determining the third number of byte blocks for carrying the 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 includes: Determining a first remainder result of taking the remainder of the calculation result of the first number and the frame header indication overhead 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, characterized in that, 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 customer service frame includes: Determining a fourth number of byte blocks for carrying the customer service frame 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 the first difference between the second number and a predetermined value, determining the expected frame header indication overhead 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 frame header indication overhead of the next service layer container as 0x1FF.

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

7. The method according to claim 6, wherein Determining a fifth quantity of customer 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 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, characterized in that, 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, characterized in that The method further includes: When the fourth quantity is greater than a first difference between the second quantity and a predetermined value, determining a sixth quantity of customer service frame byte blocks carried by the next service layer container based on the third quantity and the second quantity.

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

11. An overhead processing method, characterized in that, 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, entering a 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, characterized in that, Including: A first extraction module for extracting a frame header indication overhead from a current service layer container; A calculation module for calculating the 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 for comparing the expected frame header indication overhead with the frame header indication overhead extracted from the next service layer container, and if the comparison results are consistent for a first predetermined number of consecutive times, entering a synchronization state, where the frame header indication overhead represents the number of byte blocks between the first new customer service frame header and the start boundary of the service layer container.

14. An overhead processing device, characterized in that Including: A second extraction module for 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; 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, characterized in that, A computer program is stored in the computer-readable storage medium, 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, characterized in that, 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