A data slice processing system and method for realizing frame synchronization based on extended overhead

Abstract

This application relates to a data slicing processing system and method for frame synchronization based on extended overhead. The system includes: a transmitting end parsing the original service data stream to determine the frame header position; segmenting the data frame according to a preset slice length to generate slice data payload and slice count values; determining frame boundary association attributes and frame header offset values ​​based on frame header indicator identifiers; determining the overhead encapsulation mode based on the frame boundary association attributes; dynamically combining and mapping the slice count values, frame header offset values, and frame structure count values ​​to generate customized extended overhead and inserting it into a preset overhead position; and generating and transmitting the slice data frame. The receiving end extracts the customized extended overhead, identifies the type indicator to determine the parsing mode, and performs differentiated decoding to recover the slice count values, frame header offset values, and frame structure count values; locates the frame header start boundary based on the frame header offset value; and reconstructs the complete data frame to complete frame synchronization. This application improves the real-time performance, accuracy, and overall throughput of frame synchronization in high-speed communication networks.

Description

Technical Field

[0001] This application relates to the field of data communication and network transmission technology, and in particular to a data slicing processing system and method for achieving frame synchronization based on extended overhead. Background Technology

[0002] With the rapid development of modern communication network technology and the widespread application of emerging services such as 5G, cloud computing, and big data, the traffic carried by networks has exploded, posing unprecedented challenges to the bandwidth capacity and data forwarding speed of the underlying transmission links. To adapt to the demands of ultra-high-speed data transmission and reduce the signal processing bottleneck of a single channel, data slicing technology has emerged and been widely deployed. Data slicing technology divides large-capacity macroscopic data frames into several microscopic data slices, enabling massive amounts of business data to be interleaved and transmitted in parallel physical or logical channels, thereby greatly improving link utilization and transmission throughput. In this sliced ​​transmission architecture, frame synchronization is the core prerequisite and key foundation for the receiver to correctly reconstruct the original business data. The receiver must accurately identify the starting boundary of the data frame from the continuously received sliced ​​data stream in order to reassemble the discrete sliced ​​load according to the correct logical position. If frame synchronization is lost or misaligned, it will lead to the failure of parsing all subsequent business data and system disorder. Therefore, how to achieve frame synchronization efficiently and reliably in sliced ​​transmission scenarios has always been a core issue that urgently needs to be addressed in the field of high-speed data communication.

[0003] However, existing segmented transmission frame synchronization mechanisms still have technical flaws in practical applications. Traditional segmented transmission architectures typically employ a fixed-format overhead encapsulation strategy, forcibly inserting a complete overhead field containing all synchronization characteristics, such as frame location and offset indication, regardless of whether the current slice carries critical synchronization information. This fixed-overhead configuration severely squeezes the effective payload bandwidth within the slice that could be used for service data transmission, resulting in a significant waste of valuable channel resources and becoming a bottleneck restricting transmission efficiency. Simultaneously, during frame synchronization capture at the receiving end, traditional solutions often rely on bit-by-bit or byte-by-byte sliding correlation searches of the slice data payload to find specific frame header features. This blind traversal search mechanism not only consumes enormous logical computing resources and storage bandwidth, leading to high device power consumption, but also easily introduces unacceptable synchronization establishment delays in the face of ultra-high line-rate data streams, severely restricting the real-time processing performance and burst service response capabilities of the communication system. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a data slicing processing system and method for achieving frame synchronization based on extended overhead.

[0005] Firstly, this application provides a data slicing processing system based on extended overhead to achieve frame synchronization, employing the following technical solution:

[0006] The sending end is used to parse the acquired raw service data stream, determine the frame header position of the data frame, generate a frame header indicator, and obtain the frame structure count value of the current data frame; segment the data frame according to a preset slice length, generate slice data payloads and slice count values ​​that sequentially number the slice data payloads; determine the frame boundary association attribute and frame header offset value of the current slice data payload according to the frame header indicator; determine the overhead encapsulation mode that matches the current slice data payload according to the frame boundary association attribute, and dynamically combine and map the slice count value, the frame header offset value, and the frame structure count value according to the overhead encapsulation mode to generate a customized extended overhead carrying a type indicator; insert the customized extended overhead into the preset overhead position of the slice data payload, generate a slice data frame with customized extended overhead, and send it;

[0007] The receiving end is configured to receive slice data frames with customized extended overhead and extract the customized extended overhead; identify the type indicator in the customized extended overhead, determine the parsing mode matching the current slice data frame, and perform differentiated decoding on the customized extended overhead according to the parsing mode to recover the slice count value, and determine the frame header offset value and frame structure count value associated with the current slice; determine whether the frame header offset value is valid; if so, locate the frame header start boundary of the data frame in the slice data payload of the slice data frame according to the frame header offset value; if not, skip the frame header location operation of the current slice data payload; and reconstruct the continuously received slice data payload into a complete data frame according to the frame structure count value and in combination with the located frame header start boundary or the determination result of skipping the frame header location operation, thereby completing frame synchronization.

[0008] By adopting the above technical solution, this application proposes a mechanism for dynamically adjusting overhead encapsulation and decoding modes based on frame boundary association attributes. This breaks through the bandwidth bottleneck caused by traditional fixed overhead, assigning complete positioning information only to key slices containing frame headers, and simplifying overhead for ordinary slices, thereby improving the effective payload rate and bandwidth utilization of slice transmission. At the same time, the receiving end achieves zero-search precise positioning of the frame header directly based on the frame header offset value through differentiated decoding guided by type indicators, and achieves precise splicing and reassembly of slices by relying on dual count values. This fundamentally eliminates the high latency and high power consumption caused by traditional bit sliding search, and improves the real-time performance, accuracy, and system throughput of data frame synchronization in high-speed communication networks.

[0009] Secondly, this application provides a data slicing processing method based on extended overhead to achieve frame synchronization, applied at the sending end, and adopts the following technical solution:

[0010] The acquired raw business data stream is parsed to determine the frame header position of the data frame, generate a frame header indicator, and obtain the frame structure count value of the current data frame.

[0011] The data frame is segmented according to a preset slice length to generate slice data payloads and slice count values ​​that sequentially number the slice data payloads.

[0012] The frame boundary association attribute and frame header offset value of the current slice data load are determined based on the frame header indicator.

[0013] Based on the frame boundary association attribute, an overhead encapsulation mode matching the current slice data load is determined, and the slice count value, the frame header offset value, and the frame structure count value are dynamically combined and mapped according to the overhead encapsulation mode to generate a customized extended overhead carrying a type indicator.

[0014] The customized extended overhead is inserted into the preset overhead position of the slice data payload to generate a slice data frame with customized extended overhead and then sent.

[0015] By adopting the above technical solution, the complex and time-consuming frame search and framing process that originally needed to be performed at the receiving end is transformed into direct parsing and position jumping based on preset control information, fundamentally avoiding the dependence of traditional framing algorithms on a large amount of computing resources and time. At the same time, through the dynamic matching overhead encapsulation mode, the occupation of additional bandwidth is minimized while ensuring transmission reliability and data continuity. This achieves the best balance between reducing system latency, saving processing resources and improving transmission efficiency, thereby enhancing the performance of the communication system in high-speed, high-capacity transmission environments.

[0016] Thirdly, this application provides a data slicing processing method based on extended overhead to achieve frame synchronization, applied at the receiving end, and adopts the following technical solution:

[0017] Receive slice data frames with custom extended overhead and extract the custom extended overhead; wherein, the custom extended overhead is an overhead carrying a type indicator generated by the sender determining a matching overhead encapsulation mode based on the frame boundary association attribute of the current slice data payload, and dynamically combining and mapping the slice count value, frame header offset value and frame structure count value according to the overhead encapsulation mode.

[0018] Identify the type indicator in the customized extended overhead, determine the parsing mode that matches the current slice data frame, and perform differential decoding on the customized extended overhead according to the parsing mode to recover the slice count value, and determine the frame header offset value and frame structure count value associated with the current slice;

[0019] Determine whether the frame header offset value is valid; if yes, locate the frame header start boundary of the data frame in the slice data payload of the slice data frame according to the frame header offset value; if no, skip the frame header positioning operation of the current slice data payload.

[0020] Based on the frame structure count value and the determination result of the frame header start boundary or skip frame header positioning operation, the continuously received slice data payload is reconstructed into a complete data frame to complete frame synchronization.

[0021] By adopting the above technical solutions, a paradigm shift from "passive blind scanning" to "active navigation" is achieved at the receiving end. By parsing the customized extended overhead pre-set at the sending end, especially by using type indicators to achieve differentiated decoding and using frame header offset values ​​to achieve direct positioning, the huge processing latency and resource consumption caused by traditional frame fixing algorithms are eliminated. At the same time, by combining the continuity verification of frame structure count values ​​and slice count values, it is ensured that data frames can be quickly, accurately, and reliably reassembled in high-speed, complex cross-path transmission environments. This reduces system latency and power consumption while improving the transmission efficiency and stability of the communication network.

[0022] In summary, this application includes at least one of the following beneficial technical effects: By introducing dynamic overhead encapsulation technology based on frame boundary association attributes at the transmitting end, key slices and ordinary slices are intelligently distinguished, and optimal overhead structures are matched for them. Under the premise of almost no additional bandwidth burden, the navigation information required for frame synchronization (such as frame header offset value) is transmitted along with the slice. The receiving end uses this preset information to simplify the originally time-consuming bit-by-bit frame header search process into a one-time address calculation and verification, realizing nanosecond-level instantaneous frame fixing and reducing processing latency and hardware resource consumption. At the same time, combined with the continuity verification of frame structure count values ​​and the missing retransmission mechanism, the system effectively ensures the data integrity and order correctness in complex cross-path transmission environments, solves the contradiction between flexibility and transmission efficiency in slice transmission, and is particularly suitable for high-speed and high-capacity communication scenarios such as OTN and Ethernet, improving the throughput performance of the device and the stability of service transmission. Attached Figure Description

[0023] Figure 1 This is a first flowchart illustrating a data slicing processing method for frame synchronization based on extended overhead, which is one embodiment of this application.

[0024] Figure 2 This is a second flowchart illustrating a data slicing processing method based on extended overhead to achieve frame synchronization, which is one embodiment of this application.

[0025] Figure 3This is a schematic diagram of the third process of a data slicing processing method based on extended overhead to achieve frame synchronization, which is one embodiment of this application.

[0026] Figure 4 This is a schematic diagram of the fourth process of a data slicing processing method based on extended overhead to achieve frame synchronization, which is one embodiment of this application.

[0027] Figure 5 This is a fifth flowchart illustrating a data slicing processing method for frame synchronization based on extended overhead, according to one embodiment of this application.

[0028] Figure 6 This is a sixth flowchart of a data slicing processing method for frame synchronization based on extended overhead, according to one embodiment of this application.

[0029] Figure 7 This is a schematic diagram of the seventh process of a data slicing processing method based on extended overhead to achieve frame synchronization, which is one embodiment of this application.

[0030] Figure 8 This is a schematic diagram of the eighth process of a data slicing processing method based on extended overhead to achieve frame synchronization, which is one embodiment of this application.

[0031] Figure 9 This is a ninth flowchart illustrating a data slicing processing method for frame synchronization based on extended overhead, according to one embodiment of this application. Detailed Implementation

[0032] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-9 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0033] This application discloses a data slicing processing system that achieves frame synchronization based on extended overhead.

[0034] A data slicing processing system based on extended overhead for frame synchronization specifically includes:

[0035] The sending end parses the acquired raw service data stream, determines the frame header position of the data frame, generates a frame header indicator, and obtains the frame structure count value of the current data frame; it segments the data frame according to a preset slice length, generating slice data payloads and slice count values ​​that sequentially number the slice data payloads; it determines the frame boundary association attribute and frame header offset value of the current slice data payload based on the frame header indicator; it determines the overhead encapsulation mode that matches the current slice data payload based on the frame boundary association attribute, and dynamically combines and maps the slice count value, frame header offset value, and frame structure count value according to the overhead encapsulation mode to generate a custom extended overhead carrying a type indicator; it inserts the custom extended overhead into the preset overhead position of the slice data payload, generates a slice data frame with custom extended overhead, and sends it.

[0036] The receiving end communicates with the sending end via a high-speed serial interface to receive slice data frames with custom extended overhead and extract the custom extended overhead; it identifies the type indicator in the custom extended overhead, determines the parsing mode matching the current slice data frame, and performs differential decoding on the custom extended overhead according to the parsing mode to recover the slice count value, and determines the frame header offset value and frame structure count value associated with the current slice; it determines whether the frame header offset value is valid; if so, it locates the frame header start boundary of the data frame in the slice data payload of the slice data frame based on the frame header offset value; if not, it skips the frame header location operation of the current slice data payload; based on the frame structure count value, and combined with the located frame header start boundary or the determination result of skipping the frame header location operation, it reconstructs the continuously received slice data payload into a complete data frame, completing frame synchronization.

[0037] In the above implementation, the scheme proposes a mechanism for dynamically adjusting overhead encapsulation and decoding modes based on frame boundary association attributes. This breaks through the bandwidth bottleneck caused by traditional fixed overhead, assigning complete positioning information only to key slices containing frame headers, and simplifying overhead for ordinary slices, thereby improving the effective payload rate and bandwidth utilization of slice transmission. At the same time, the receiving end achieves zero-search precise positioning of the frame header directly based on the frame header offset value through differentiated decoding guided by type indicators, and achieves precise splicing and reassembly of slices by relying on dual count values. This fundamentally eliminates the high latency and high power consumption caused by traditional bit sliding search, and improves the real-time performance, accuracy, and system throughput of data frame synchronization in high-speed communication networks.

[0038] This application also discloses a data slicing processing method based on extended overhead to achieve frame synchronization, based on the transmitting end.

[0039] Reference Figure 1 A data slicing processing method based on extended overhead for frame synchronization is applied to the sending end. The specific method includes:

[0040] Step S101: Parse the acquired raw business data stream, determine the frame header position of the data frame, generate a frame header indicator, and obtain the frame structure count value of the current data frame.

[0041] In communication protocols such as OTN (Optical Transport Network), service data is usually encapsulated in a continuous frame structure, and each frame has a specific frame header (Frame Alignment Signal, FAS) as a synchronization reference.

[0042] In this embodiment, the first step utilizes the physical layer or link layer frame positioning mechanism to accurately capture the start boundary of the data frame. This process is similar to identifying the start page number of each page in a digital signal stream. Once the frame header position is locked, the system immediately generates a "frame header indicator," which is essentially a high-level pulse or a specific sequence of flag bits. This indicator is used to mark the start time of the frame in subsequent parallel processing logic, thereby avoiding the need to repeatedly perform time-consuming frame searches at each processing stage.

[0043] Meanwhile, the system reads or maintains a frame structure count, a globally incrementing counter used to uniquely identify the absolute position of the current data frame within the entire service flow. The frame structure count is initially 0, incremented by the sender at the beginning of each frame; it can be encoded as a 16-bit unsigned integer, wrapping back to 0 after overflow. The receiver detects overflow through continuity checks. During a cold start, the receiver waits for the first critical slice to acquire the frame structure count to initialize its local buffer. This counter allows the receiver to determine whether frames have been lost or out of order by comparing the continuity of the count, even after multi-hop transmissions, thus laying a timing foundation for subsequent high-reliability transmission.

[0044] For example, in a high-speed OTN line, service node A continuously receives STM-16 signals from the client side. The signal generates a frame every 125 microseconds. The system will add a precise frame header indicator at the beginning of each frame and record the sequence number of the frame (such as frame 1024) as the frame structure count value, providing a precise coordinate system for subsequent slicing operations.

[0045] Step S102: Divide the data frame according to the preset slice length to generate slice data payload and slice count value that sequentially numbers the slice data payload;

[0046] The preset slice length can be selected based on the minimum scheduling unit of the cross matrix or to optimize the balance between transmission efficiency and latency, for example, by setting it to a fixed 128 bytes or 256 bytes. The segmentation process is not a simple physical truncation, but rather a logical division of the frame payload into several consecutive slice data payload blocks.

[0047] To ensure that these scattered slices can be accurately reconstructed into the original frame at the receiving end, the system must assign a slice count value to each slice. This count value increments sequentially within a single frame, indicating not only the relative position of the slice within the current frame (e.g., slice 1, slice 2, etc.) but also the implicit order of the slices. This mechanism solves the inherent problem of out-of-order reassembly in slice transmission. For example, a data frame containing a 1024-byte payload, if the preset slice length is 256 bytes, will be divided into four slices, and the system will assign them slice count values ​​of 0, 1, 2, and 3 respectively. Thus, even if these four slices traverse different physical paths in a complex switching network, the receiving end can quickly reassemble them into the original 1024-byte payload based on the slice count values, without data misalignment due to path delay differences.

[0048] Step S103: Determine the frame boundary association attribute and frame header offset value of the current slice data load based on the frame header indicator.

[0049] Since slicing operations are initiated randomly, a slice may be entirely within the frame (excluding the frame header) or it may just contain the frame's start boundary (including the frame header). Therefore, frame boundary association attributes are used to define this relationship: the system classifies frame boundary association attributes based on whether a slice contains a frame header. If a slice contains the start position indicated by the frame header, its attribute is marked as 'critical slice type'; conversely, if a slice does not contain a frame header (whether in the middle or at the end of the frame), it is uniformly marked as 'normal slice type'. The receiving end can implicitly deduce the position of the frame tail in a normal slice by recognizing the frame structure count jumps of subsequent critical slices.

[0050] It is important to emphasize that for those cases marked as "critical slice types," a "frame header offset value" needs to be further calculated. The frame header offset value is a relative address that indicates the precise location of the frame header within the slice (e.g., the frame header is located at the 16th byte of the slice). This fine-grained attribute division allows the receiving end to avoid performing a full scan of the entire slice data to find the frame header. Instead, it can quickly determine whether the slice is worth searching for the frame header based on the "frame boundary association attribute" and directly jump to the exact location of the frame header using the "frame header offset value."

[0051] For example, assuming a slice length of 256 bytes, and the frame header falls exactly at the 32nd byte within a slice, then the frame boundary association attribute of that slice is "including frame header," with a frame header offset of 32. When the receiving end reads this slice, it can skip the first 31 bytes and directly verify the frame header at the 32nd byte, greatly improving framing efficiency.

[0052] Step S104: Determine the overhead encapsulation mode that matches the current slice data load based on the frame boundary association attribute, and dynamically combine and map the slice count value, frame header offset value and frame structure count value according to the overhead encapsulation mode to generate a customized extended overhead carrying a type indicator.

[0053] Specifically, the system dynamically selects the most suitable overhead encapsulation mode based on the "frame boundary association attribute" determined in the previous step. For example, for "critical slice type", since it contains critical frame synchronization information, its overhead encapsulation mode will include the complete frame structure count value, slice count value, and frame header offset value to ensure that the receiver can reconstruct the complete frame timing. For "ordinary slice type", since frame header information is not required for synchronization, its overhead encapsulation mode may omit the frame header offset value or adopt a more concise format, thereby saving valuable bandwidth resources.

[0054] Understandably, this dynamic combination mapping process involves encoding and arranging discrete control information such as slice counts, frame header offsets, and frame structure counts according to a selected encapsulation mode (i.e., a predefined binary data structure template). For example, "dynamic combination mapping uses bit-field concatenation, with a customized extension overhead of 16 bits. The highest two bits are type indicators (00 = critical slice mode, 01 = normal slice mode), the middle six bits are slice counts, and the lower eight bits are the frame header offset in critical slice mode and the lower eight bits of the frame structure count in normal slice mode."

[0055] Finally, the generated custom extended overhead also includes a type indicator, a short code used to inform the receiver of the encapsulation mode used by the current overhead so that the receiver can use the correct parsing rules.

[0056] Step S105: Insert the custom extended overhead into the preset overhead position of the slice data payload, generate a slice data frame with custom extended overhead, and send it.

[0057] Specifically, in a communication system, a data frame consists of an "overhead area" and a "payload area." This step precisely inserts customized extended overhead into a preset overhead position before the sliced ​​data payload. This position is either a fixed number of bytes reserved according to communication standards (such as ITU-T G.709) or a specific position defined internally by the device. This insertion operation must ensure data continuity and must not disrupt the byte order of the sliced ​​data payload itself.

[0058] Ultimately, the resulting sliced ​​data frame with customized overhead is a complete transmission unit. It not only carries business data but also crucial navigation information for accelerating framing and ensuring continuity. These sliced ​​data frames are then sent to the cross-path for transmission. For example, in an OTN system, this is equivalent to inserting a custom overhead before the standard OPUk payload. This overhead acts like a smart label on a package, clearly indicating the item's serial number, the box number, and the box's location within the container, allowing the transit station (receiving end) to instantly identify and process the data without having to open the boxes and count each item individually.

[0059] In the above implementation, the complex and time-consuming frame search and framing process that originally needed to be performed at the receiving end is transformed into direct parsing and position jumping based on preset control information, which fundamentally avoids the dependence of traditional framing algorithms on a large amount of computing resources and time. At the same time, through the dynamic matching overhead encapsulation mode, the occupation of additional bandwidth is minimized while ensuring transmission reliability and data continuity. Thus, the best balance is achieved between reducing system latency, saving processing resources and improving transmission efficiency, thereby enhancing the performance of the communication system in high-speed, high-capacity transmission environments.

[0060] Reference Figure 2 As one implementation of step S102, the steps of segmenting the data frame according to a preset slice length, generating slice data payloads and slice count values ​​that sequentially number the slice data payloads include:

[0061] Step S201: Configure the slice counter and segment the data frame according to the preset slice length to generate the current slice data load;

[0062] Specifically, first, the system needs to initialize the slice counter, which acts as a slice sequence generator. The initial value setting (e.g., setting it to 0 or 1) defines the starting reference for slice numbering, ensuring the uniqueness of slice identifiers across the entire network or at least within the same data stream context.

[0063] Next, the system mechanically segments the byte stream of the data frame according to a preset slice length (a fixed value determined after balancing transmission efficiency, switching matrix scheduling granularity, and encapsulation overhead, such as 128 bytes). This process is not a simple truncation, but a logical boundary division, which decomposes a complete data frame, which may contain thousands of bytes, into several consecutive current slice data payloads.

[0064] For example, in an OTN line-side processing scenario, when a service node receives a standard OTUk frame, the hardware processing logic starts the slicing engine and slides the frame from the beginning position according to the configured 128-byte window. The first 128 bytes are the "current slice data load". This processing method effectively adapts large-granularity services into small-granularity switching channels and is the basic physical action for achieving flexible bandwidth scheduling.

[0065] In this embodiment, the slice counter can be an 8-bit unsigned integer, which wraps back to 0 after overflow; the receiving end detects the start of a new frame by the jump of the frame structure count value, avoiding sorting disorder caused by the wrapping of the slice count value.

[0066] Step S202: Obtain the current count value of the slice counter, assign the current count value to the current slice data load as the corresponding slice count value, and perform an increment operation on the slice counter;

[0067] Simultaneously with generating a slice data payload, the system immediately captures the current count value of the "slice counter." This count value is not merely a number; it is a metadata tag used to precisely indicate the relative position and order of the slice within the original frame when the data frame is reconstructed at the receiving end. Assigning this count value to the slice data payload essentially establishes a strong association mapping: that is, "data block A belongs to the Nth slice."

[0068] To prevent subsequent slices from being assigned duplicate numbers, the system must immediately increment the slice counter (e.g., set it to +1) after assignment. This atomic sequence of operations (get-assign-increment) ensures that the slice counter value will not conflict or jump even in a high-speed parallel processing environment. In the embodiments of this application, the counter increment operation satisfies Cn=C n−1 +1, where C n C is the slice count value of the nth slice data load. n−1 This is the count value of all previous pieces.

[0069] For example, if the current slice counter value is 5, the newly generated slice data payload is marked as "slice 5". The counter then increments to 6, and the next slice naturally becomes "slice 6". This strict sequential numbering mechanism provides the receiving end with a natural sorting basis that can be implemented without complex algorithms, avoiding the problem of out-of-order reordering caused by different network transmission paths.

[0070] Step S203: Associate the current slice data load with the corresponding slice count value and store it in the cache queue. Continue to segment and cut the uncut part of the data frame until the data frame is cut. Generate all slice data loads and corresponding slice count values.

[0071] By associating slice data payloads with their corresponding count values, the system constructs a data structure (such as an array of structures or linked list nodes) that encapsulates the data itself and its control information (count values). This associative storage is typically written to a cache queue (such as a FIFO, First-In-First-Out memory). The cache queue provides a stable data source for subsequent overhead encapsulation processing modules, smoothing out traffic and decoupling the processing flow.

[0072] Meanwhile, the system logic immediately backtracks to the uncut portion of the data frame and repeats the cutting, numbering, and enqueueing operations. This is a typical iterative process, and its termination condition is strictly defined as "the data frame has been cut," that is, the end boundary of the original data frame has been reached. This step is only considered complete when the entire data frame has been completely converted into a series of slice data payloads with consecutive count values ​​and all of them have been stored in the buffer queue.

[0073] For example, for a 1000-byte data frame, with a slice length of 128 bytes, the system will perform a loop cutting 7 times (the first 6 times are full slices, and the last time is a remaining 88-byte slice). Each time, the generated slice and its number (0 to 6) are pushed into the buffer queue. Ultimately, the buffer queue holds the complete sliced ​​mapping of the data frame, waiting for the next step of expansion overhead encapsulation.

[0074] The above implementation achieves efficient and orderly slicing of high-speed service data streams. By introducing a slice counter and a cache queue mechanism, it not only ensures the traceability of the slice data load order during transmission and eliminates the risk of logical confusion during reassembly at the receiving end, but also decouples the two processing stages of slice generation and overhead encapsulation by using a cache. This effectively smooths out fluctuations in data processing rate, improves the system's throughput stability and adaptability to sudden traffic, and lays a solid data foundation for subsequent fast frame synchronization based on extended overhead.

[0075] Reference Figure 3 As one implementation of step S103, the step of determining the frame boundary association attribute and frame header offset value of the current slice data payload based on the frame header indication identifier includes:

[0076] Step S301: Obtain the frame header indicator corresponding to the current slice data payload and determine the address range of the current slice data payload in the data frame;

[0077] The frame header indicator is an absolute coordinate (e.g., at the Nth byte in the original byte stream) generated by the frame positioning signal in the preceding steps to mark the start position of the original data frame.

[0078] At the same time, the system must determine the address range of the current slice data payload within the original data frame. This range is determined by its starting point and the preset slice length, i.e., a closed interval from the "starting byte address" to the "ending byte address". For example, if the original data frame starts at address 0 and the preset slice length is 128 bytes, then the address range of the first slice data payload is 0 to 127, the second is 128 to 255, and so on. Determining this address range provides a precise geographic coordinate system for subsequently determining whether the frame header falls within the slice, and is the physical basis for frame boundary association and classification.

[0079] Step S302: Determine whether the frame header position corresponding to the frame header indicator is within the address range; if yes, proceed to step S303; if no, proceed to step S304.

[0080] Specifically, if the value of the frame header indicator is greater than or equal to the start address of the slice and less than or equal to the end address of the slice, it is determined to be "within the range". This judgment process can be quickly implemented in the hardware logic using a comparator circuit, and its result will directly determine the subsequent processing strategy for that slice.

[0081] For example, in an OTN frame processing scenario, if the frame header indicator points to address 100 and the address range of the current slice is 0-127, then the judgment result is true, indicating that the slice contains the start boundary of the frame; conversely, if the slice address range is 128-255, then the judgment is false.

[0082] Step S303: Mark the frame boundary association attribute of the current slice data load as a key slice type, and calculate and generate a frame header offset value based on the frame header position and the starting position of the address range.

[0083] When the result indicates that the frame header is located inside a slice, the slice is identified as a critical slice type because it contains the anchor point information necessary for the receiver to perform frame synchronization.

[0084] At this point, the system needs to further calculate the frame header offset value, which is a relative address used to precisely indicate the microscopic location of the frame header within the slice. The calculation method is to subtract the starting address of the current slice's data payload from the absolute address indicated by the frame header. For example, if the frame header is at absolute address 100 and the slice starts at address 64, then the frame header offset value is 36, meaning that the frame header is located at the 36th byte counting from the leading byte of the slice.

[0085] Understandably, this offset calculation allows the receiving end to directly locate the frame header without scanning the entire slice, greatly improving framing efficiency. Marking the slice as a critical type and attaching an offset value is equivalent to attaching a smart label to the header of the slice data packet that reads "Contains frame header, offset is X," providing precise navigation for the receiving end's rapid processing.

[0086] Step S304: Mark the frame boundary association attribute of the current slice data load as a normal slice type, and configure the frame header offset value to a preset invalid status code.

[0087] When the judgment result is that the frame header is not within the current slice range, the slice only contains service data payload and does not contain any frame synchronization information. Therefore, the frame header information is irrelevant to the frame fixing operation of the receiving end.

[0088] To reflect this fact and avoid unnecessary frame header searches at the receiver, the system forces the "frame header offset value" to be configured with a predefined "invalid status code". This invalid status code can be a binary number consisting entirely of 1s (e.g., 11111111 for an 8-bit offset value), as all 1s are conventionally used in most systems to indicate errors or invalidity. This approach not only clarifies the functional attributes of the slice but also prevents the receiver from misinterpreting meaningless offset values ​​through the invalid code, ensuring the logical completeness and robustness of the system.

[0089] The above implementation achieves refined classification and management of slice data load. By accurately calculating the frame header offset value and binding it with the slice attributes, the receiving end can selectively and efficiently frame according to the slice type label. This avoids the huge waste of resources and processing delay caused by blindly scanning all slices in the traditional method, thereby improving the overall transmission efficiency and real-time performance of the system while ensuring frame synchronization accuracy.

[0090] Reference Figure 4 As one implementation of step S104, the step of determining an overhead encapsulation mode that matches the current slice data load based on the frame boundary association attribute, and dynamically combining and mapping the slice count value, frame header offset value, and frame structure count value according to the overhead encapsulation mode to generate a customized extended overhead carrying a type indicator includes:

[0091] Step S401: Obtain the frame boundary association attribute of the current slice data load, as well as the slice count value, frame header offset value, and frame structure count value corresponding to the current slice data load;

[0092] Among them, the frame boundary association attribute is marked as either a "critical slice type" or a "normal slice type" by determining whether the frame header falls within the slice range, which directly determines the structural complexity of the overhead; the slice count value is the sequential number of the slice within the original data frame, used for sequence verification during reassembly at the receiving end; the frame header offset value is the byte distance of the frame header in the critical slice relative to the slice start boundary, which is the core coordinate for the receiving end to quickly locate the frame header; the frame structure count value is a globally unique identifier of the original data frame, used to verify the continuity of frames across slices.

[0093] Step S402: Based on the frame boundary association attribute, determine the overhead encapsulation mode that matches the current slice data load as the target encapsulation mode.

[0094] Specifically, when the frame boundary association attribute is a critical slice type, the target encapsulation mode is determined to be the first mode; when the frame boundary association attribute is a normal slice type, the target encapsulation mode is determined to be the second mode.

[0095] In this embodiment, the encapsulation strategy is dynamically switched through frame boundary association attributes to avoid redundant overhead consuming valuable bandwidth. Critical slice types, because they contain frame header information, require the transmission of more synchronization control data (such as frame header offset values ​​and frame structure count values), and therefore match the first mode. This mode has a more complex overhead structure but can provide complete frame navigation for the receiving end. Ordinary slice types do not contain frame headers and only need to transmit slice order information, therefore match the second mode. This mode has a more streamlined overhead structure, retaining only the necessary slice count values ​​and frame structure count values ​​(used to verify frame continuity).

[0096] For example, in a 100G OTN line, if each frame is divided into 10 slices, of which only one is a critical slice, using dynamic mode can reduce the total overhead by about 30% without affecting frame fixing performance.

[0097] Step S403: According to the field mapping rules defined in the target encapsulation mode, the slice count value, frame header offset value and frame structure count value are dynamically combined and mapped to generate a combined data block;

[0098] Specifically, when the target encapsulation mode is the first mode, the slice count value, frame header offset value, and frame structure count value are mapped and combined into a combined data block; when the target encapsulation mode is the second mode, only the slice count value and frame structure count value are mapped and combined into a combined data block.

[0099] Specifically, the field mapping rule is a pre-set encapsulation blueprint in the system: the first mode corresponds to a wider bit-width template (such as N bits), which contains three fixed areas. The first data area stores the slice count value (occupying A bits), the second data area stores the frame header offset value (occupying B bits), and the third data area stores the frame structure count value (occupying C bits); the second mode corresponds to a narrower bit-width template (such as M bits, M < N), and only the first data area (slice count value) and the third data area (frame structure count value) are retained.

[0100] It can be understood that the essence of dynamic combination mapping is to fill the metadata into the corresponding positions of the template. For example, if the slice count value in the first mode occupies 8 bits, the frame header offset value occupies 4 bits, and the frame structure count value occupies 12 bits, then the combined data block is the continuous splicing of these three fields. This regular mapping ensures the consensus on the overhead structure between the sender and the receiver, avoiding parsing errors caused by inconsistent formats.

[0101] Step S404, perform forward error correction encoding on the combined data block to generate a check code, and append the check code to the combined data block to generate the encoded overhead field;

[0102] Among them, the combined data block serves as the core navigation information for frame alignment. Once a bit error occurs during transmission, it will directly lead to frame alignment failure at the receiving end. Therefore, error correction protection must be carried out.

[0103] Specifically, the system can use FEC algorithms such as Reed-Solomon coding or Hamming coding to calculate the combined data block and generate multiple-bit check codes. These check codes can detect and correct a certain number of bit errors (for example, Reed-Solomon coding can correct up to 4 symbol errors). The check codes are appended to the end of the combined data block to form the encoded overhead field, equivalent to adding an "error-proof shell" to the navigation information. For example, in high-speed OTN transmission, noise in the optical fiber may cause 1-2 bit errors in the overhead field, and FEC coding enables the receiving end to automatically repair these errors, avoiding expensive retransmission processes triggered by overhead damage.

[0104] Step S405, generate a corresponding type indicator field according to the target encapsulation mode;

[0105] Among them, the type indicator field is a short code (usually 1 bit), and its value corresponds one-to-one with the first mode or the second mode (such as "0" represents the first mode and "1" represents the second mode). Its function is to eliminate the parsing ambiguity at the receiving end.

[0106] Specifically, when the receiver reads a type indicator of "0", it knows that the subsequent overhead includes the frame header offset value and needs to be parsed using the rules of the first mode; if it is "1", only the slice count value and frame structure count value are parsed. This logic of identifying before parsing avoids the latency caused by the receiver trying multiple modes for parsing, thus improving processing efficiency. For example, in hardware implementation, the type indicator can be directly connected to the demultiplexer selection terminal of the receiver to achieve zero-latency mode switching.

[0107] Step S406: Concatenate the type indicator field with the encoded overhead field to generate a custom extended overhead.

[0108] The concatenation order follows the principle of "identifier first, data later": the type indicator field is placed at the very beginning (most significant bit) of the encoded overhead field, forming a continuous binary stream. This structure ensures that the receiving end obtains the parsing rules as soon as it reads the overhead, and then processes the subsequent control information in sequence. For example, if the type indicator occupies 1 bit and the encoded overhead field occupies 24 bits, then the customized extended overhead, totaling 25 bits, can be directly inserted into the preset overhead position of the sliced ​​data payload (such as the overhead byte area of ​​an OTN frame).

[0109] In the above implementation, dynamic adaptation and reliability assurance of overhead encapsulation are achieved. By switching the encapsulation mode driven by the frame boundary association attribute, the overhead ratio of ordinary slices is maximized while ensuring the integrity of the synchronization information of key slices, effectively saving transmission bandwidth. Combined with forward error correction coding and type indicator design, the anti-interference capability of overhead information is improved and the parsing complexity of the receiver is reduced. Ultimately, the frame fixing latency of the receiver is greatly reduced, processing resources are saved, and the continuity of data transmission is reliably guaranteed, which can perfectly adapt to the dual requirements of high-speed OTN networks for flexibility and efficiency.

[0110] Reference Figure 5 As a further implementation of the data slicing processing method, before parsing the acquired raw business data stream, the method further includes:

[0111] Step S501: Obtain the quality index data of the current network channel, and extract the bit error rate and channel load rate from the quality index data;

[0112] Among them, the bit error rate (BER) is the core indicator for measuring the reliability of channel transmission. It reflects the probability of errors occurring in bit-level data during transmission. A higher BER indicates more severe channel noise interference or greater signal attenuation. The channel load rate is a key indicator for reflecting the utilization of channel bandwidth resources, representing the current degree of network congestion and remaining available capacity.

[0113] By extracting data from these two dimensions, we essentially establish a dual-engine driven perception foundation for the subsequent adaptive overhead allocation mechanism. This takes into account both the bottom-line requirements of transmission (reliability) and the efficiency requirements of transmission (bandwidth margin), avoiding the policy bias that may result from evaluating a single indicator.

[0114] Step S502: Calculate the overhead optimization coefficients based on the bit error rate and channel load rate values;

[0115] The logic of this step is to normalize and fuse the physical dimensions of the two heterogeneous dimensions. Since the bit error rate and channel load rate differ in numerical range and weight of their impact on transmission strategy, a pre-set statistical algorithm is used to fuse them into a single overhead optimization coefficient, which can intuitively and quantitatively reflect the current channel overall state's demand for overhead redundancy.

[0116] In this embodiment, the overhead optimization coefficient can be calculated using the weighted sum of the bit error rate (BER) and channel load rate (CLR) values. The calculation formula can be set as OOC = α·(BER / BER_ref) + β·LR, where OOC represents the overhead optimization coefficient, BER represents the current channel BER value, BER_ref represents the system-preset baseline BER constant used to eliminate dimensional differences and achieve normalization, LR represents the channel load rate value and its value range is normalized to between 0 and 1, and α and β represent the BER weighting coefficient and the load rate weighting coefficient, respectively, and are configured such that α is greater than β (e.g., α is 0.65 and β is 0.35).

[0117] Understandably, this weighting mechanism prioritizes the impact of a deteriorating bit error rate on the overhead optimization coefficient over the impact of an increased load rate. This ensures that the core logic of prioritizing the reliable transmission of frame synchronization control plane information is implemented in the trade-off between limited bandwidth resources and the guarantee of synchronization reliability. It also ensures that the final calculated coefficient value can accurately quantify the current channel's urgent need for additional overhead redundancy.

[0118] Step S503: Compare the cost optimization coefficients with the predefined first threshold and second threshold respectively, and generate dynamic cost adjustment parameters based on the comparison results;

[0119] Specifically, when the cost optimization coefficient is lower than the first threshold, a first adjustment parameter representing a simplified cost strategy is generated; when the cost optimization coefficient is higher than the second threshold, a second adjustment parameter representing a complete cost strategy is generated; and when the cost optimization coefficient is between the first and second thresholds, a third adjustment parameter representing a balanced cost strategy is generated.

[0120] In this embodiment, this step introduces a dual-threshold interval division mechanism to achieve a refined hierarchical response to the channel state. Specifically, when the overhead optimization coefficient is lower than the first threshold, it indicates that the current channel quality is excellent and the bandwidth is sufficient, and transmission can be guaranteed without a large amount of redundant overhead. Therefore, a first adjustment parameter representing the simplified overhead strategy is generated. When the overhead optimization coefficient is higher than the second threshold, it means that the channel environment is poor or extremely congested, and maximum redundancy must be injected to combat bit errors and ensure the delivery of synchronization information. Therefore, a second adjustment parameter representing the complete overhead strategy is generated. When the overhead optimization coefficient is between the first and second thresholds, it represents that the channel state is at a moderate level. At this time, a third adjustment parameter representing the balanced overhead strategy is generated.

[0121] For example, during periods of low traffic at night when the channel is excellent, the system generates the first adjustment parameter to minimize differentiation overhead; during peak hours in the evening when wireless backhaul is congested and interference is strong, the system generates the second adjustment parameter to ensure control plane reachability; and during stable periods of daily office work, the system generates the third adjustment parameter to achieve a trade-off between reliability and efficiency.

[0122] It should be noted that the first threshold and the second threshold can be determined based on the physical layer bit error rate statistics. The first threshold is 1E-5 and the second threshold is 1E-3.

[0123] Step S504: Generate verification code configuration parameters and field mapping configuration parameters according to the dynamic overhead adjustment parameters; wherein, according to the first adjustment parameter, generate field mapping configuration parameters corresponding to reduced bit width and verification code configuration parameters for simplified verification; according to the second adjustment parameter, generate field mapping configuration parameters corresponding to extended bit width and verification code configuration parameters for enhanced verification; and according to the third adjustment parameter, generate field mapping configuration parameters corresponding to standard bit width and verification code configuration parameters for standard verification.

[0124] Specifically, based on the first adjustment parameter, the system generates field mapping configuration parameters corresponding to reduced bit width and check encoding configuration parameters for simplified verification. This involves compressing the bit depth of fields such as slice counts during mapping and employing a simplified check mode with weaker error correction capabilities but lower encoding overhead to maximize payload bandwidth release. Based on the second adjustment parameter, it generates field mapping configuration parameters corresponding to extended bit width and check encoding configuration parameters for enhanced verification. This involves preserving or extending the full bit depth of fields and enabling a strong error correction encoding mode to resist deep fading and bit errors. Based on the third adjustment parameter, it generates field mapping configuration parameters corresponding to standard bit width and check encoding configuration parameters for standard verification, achieving conventional bit width allocation and moderate-strength encoding protection. This process ensures that the policy intent is accurately translated into bit width and encoding configuration instructions executable by the underlying hardware.

[0125] Step S505: Store the verification encoding configuration parameters and field mapping configuration parameters in the configuration register so that when dynamically combining and mapping the slice count value, frame header offset value and frame structure count value according to the overhead encapsulation mode, the field mapping configuration parameters are called to determine the mapping bit width, and when performing forward error correction encoding on the combined data block, the verification encoding configuration parameters are called to determine the verification mode type.

[0126] Among them, the configuration register serves as the control hub for software and hardware interaction. It caches the results of the previous environmental perception and policy calculation as static control quantities. This allows subsequent data frames on the pipeline to directly read the mapping bit width in the register to trim or extend the physical length of the field when performing dynamic combination mapping. Furthermore, when performing forward error correction coding, it directly calls the check mode type in the register to select the corresponding error correction coding algorithm. This decouples the environmental adaptive adjustment and high-speed data plane processing at the micro-timing level, ensuring that frame synchronization information can be reliably transmitted in fluctuating channels without excessively crowding out the payload.

[0127] In the above implementation, a closed-loop adaptive control mechanism is constructed from the underlying channel state perception to the dynamic reconstruction of the top-level overhead structure, overcoming the limitation that the fixed overhead format in traditional slice transmission cannot adapt to dynamic channel changes. The system accurately calculates optimization coefficients based on both bit error rate and load rate, and uses dual thresholds to divide three progressive overhead strategies: simplified, balanced, and complete. These strategies are then converted into specific mapping bit widths and error correction coding control parameters and stored in registers for subsequent use. This ensures that each slice encapsulation achieves an optimal trade-off between "reliability assurance" and "bandwidth efficiency improvement" under the current channel conditions. This avoids bandwidth waste caused by excessive redundant overhead in excellent channels and eliminates frame synchronization loss caused by insufficient overhead protection in poor channels, thereby improving the overall transmission efficiency and synchronization robustness of the communication system in heterogeneous and fluctuating network environments.

[0128] This application also discloses a data slicing processing method based on extended overhead to achieve frame synchronization on the receiving end side.

[0129] Reference Figure 6 A data slicing processing method based on extended overhead for frame synchronization, applied at the receiving end, specifically includes:

[0130] Step S601: Receive the slice data frame with custom extended overhead and extract the custom extended overhead;

[0131] Among them, the customized extended overhead is the overhead carrying type indicator generated by the sender determining the matching overhead encapsulation mode based on the frame boundary association attribute of the current slice data load, and dynamically combining and mapping the slice count value, frame header offset value and frame structure count value according to the overhead encapsulation mode.

[0132] Specifically, in communication systems such as OTN, data frames typically arrive as a continuous stream of bytes. The receiving end first needs to use physical layer synchronization mechanisms (such as the Frame Positioning Signal, FAS) to lock the boundaries of the data frame, and then locate the fixed position of the "custom extended overhead" (e.g., a specific column of the OTN overhead bytes) according to the predefined frame structure definition. The extraction process essentially separates the control information embedded in the service data stream into an independent binary data block. This data block is the result of intelligent encapsulation by the sending end: it contains a type indicator (used to tell the receiving end how to parse it) as well as slice count values, frame header offset values, and frame structure count values ​​protected by forward error correction coding.

[0133] For example, in the receiver hardware logic, when the existence of a specific overhead byte region is detected, a DMA (direct memory access) operation is automatically triggered to copy the bytes of that region into a dedicated overhead parsing buffer, providing clean input data for subsequent frame processing.

[0134] Step S602: Identify the type indicator in the custom extended overhead, determine the parsing mode that matches the current slice data frame, perform differential decoding on the custom extended overhead according to the parsing mode, recover the slice count value, and determine the frame header offset value and frame structure count value associated with the current slice.

[0135] The type indicator occupies the most significant bit (e.g., 1 bit) of the overhead field, and its value (e.g., "0" or "1") directly corresponds to the first or second encapsulation mode used by the transmitter. After the receiver recognizes this indicator, it can select the matching mode from a variety of pre-stored parsing modes and load the corresponding bit width allocation template and decoding rules.

[0136] Understandably, this differentiated decoding avoids blind trial and error and improves processing efficiency. For critical slices (type indicator corresponds to the first mode), the decoding process will fully extract the slice count value (for sorting), frame header offset value (for locating the frame header), and frame structure count value (for verifying frame continuity); for ordinary slices (type indicator corresponds to the second mode), only the slice count value and frame structure count value are extracted, and the frame header offset value is in a preset invalid state.

[0137] Furthermore, before differential decoding, the encoding overhead field must first undergo forward error correction (FEC) decoding. This uses additional checksums to automatically correct any bit errors that may occur during transmission, restoring the encoding overhead field to a clean combined data block and ensuring the absolute reliability of subsequent control information extraction. For example, when the receiving FPGA logic reads a type indicator of "0", it first performs FEC decoding on the subsequent bitstream, then activates a 24-bit wide parser to parse the slice count, frame header offset, and frame structure count from bits 0-7, 8-11, and 12-23, respectively.

[0138] Step S603: Determine whether the frame header offset value is valid; if yes, proceed to step S604; if no, skip the frame header positioning operation of the current slice data load.

[0139] Step S604: Based on the frame header offset value, locate the frame header start boundary of the data frame in the slice data payload of the slice data frame.

[0140] For types marked as critical slices, the receiver has successfully recovered the frame header offset value, which is a relative address indicating the offset of the original data frame's frame header start byte within the current slice's data payload.

[0141] Understandably, the receiving end only needs to perform a simple addition operation (starting address of the slice data payload + frame header offset) to directly jump to the exact location of the frame header, without needing to perform frame header pattern matching byte by byte in each slice as in traditional methods. This direct addressing mechanism reduces the time complexity of the frame determination operation from O(N) (scanning the entire slice) to O(1) (single calculation), which is key to reducing latency. For example, if the starting address of the slice data payload in memory is 0x1000 and the recovered frame header offset is 0x20, the receiving end immediately knows that the frame header is located at physical address 0x1020, and can then read the content at that address for frame header verification.

[0142] Step S605: Based on the frame structure count value and the determination result of the located frame header start boundary or skip frame header positioning operation, the continuously received slice data payload is reconstructed into a complete data frame to complete frame synchronization.

[0143] The frame structure count, acting as a global timing tag, is responsible for classifying and verifying the continuity of scattered received slices according to their original frames, ensuring that the reconstructed frames are not misaligned. The determined frame header start boundary or skip location decision serves as the basis for local physical addressing. For critical slices, their frame header boundaries are written as the absolute starting address, ensuring precise alignment of the starting physical position of each frame. For ordinary slices, the skip location decision is used to sequentially continue writing from the previous position. This combination ensures both the complete splicing of slices in the logical frame structure and the absolute positioning of the frame header in physical memory, thus reconstructing continuous original data frames without errors.

[0144] Specifically, for critical slices, the receiving end uses the frame header start boundary located in the previous step to confirm that the current slice is the beginning of a frame. Then, using the recovered "frame structure count value" as an index, the current slice is placed into the corresponding frame slot in the reassembly buffer. Simultaneously, the system monitors the "slice count value" in the continuously received slice data payload to ensure they arrive in order, thus arranging and concatenating all slices belonging to the same frame (e.g., slices 0, 1, 2...N) in the buffer in order. Once all slices of a frame have arrived and passed the continuity check, the receiving end uses the frame header start boundary as a reference, removes slice overhead, and continuously outputs the clean service data payload, thereby completing the entire frame synchronization and reassembly process.

[0145] For example, after receiving all the slices with a frame structure count value of 100, the receiving end will check whether the slice count values ​​from 0 to 9 are complete. After confirming that there are no errors, it will sequentially splice the data payloads of these slices to recover the complete data frame number 100 and deliver it to the upper layer service processing unit.

[0146] In the above implementation, a paradigm shift from "passive blind scanning" to "active navigation" is achieved at the receiving end. By parsing the customized extension overhead preset at the sending end, especially by using type indicators to achieve differentiated decoding and using frame header offset values ​​to achieve direct positioning, the huge processing latency and resource consumption caused by traditional frame fixing algorithms are eliminated. At the same time, by combining the continuity verification of frame structure count values ​​and slice count values, it is ensured that data frames can be quickly, accurately, and reliably reassembled in high-speed and complex cross-path transmission environments, thereby reducing system latency and power consumption while improving the transmission efficiency and stability of the communication network.

[0147] Reference Figure 7 As one implementation of step S602, the steps of identifying the type indicator in the custom extended overhead, determining the parsing mode matching the current slice data frame, differentially decoding the custom extended overhead according to the parsing mode, recovering the slice count value, and determining the frame header offset value and frame structure count value associated with the current slice include:

[0148] Step S701: Read the type indicator field from the custom extension overhead;

[0149] Specifically, in communication systems such as OTN, customized extended overhead is typically encapsulated in a fixed overhead region (such as the first N bytes) of the sliced ​​data frame. The type indicator field, as the "header" of the overhead, generally occupies the most significant bit (MSB), and its value (such as "0" or "1") directly reflects the encapsulation strategy adopted by the sender for that slice.

[0150] In this embodiment, the read operation can be completed via hardware register shifting: after the receiving end locks the frame synchronization, it continuously reads the bit stream from the starting address of the overhead region and latches the first bit or the first few bits into the type indicator register. For example, in an 8-bit wide overhead bus, the receiving end logic monitors the highest bit (bit 7). If this bit is 0, it is determined to be the first parsing mode; if it is 1, it is determined to be the second parsing mode. This read mechanism is simple and efficient, requiring no complex calculations, and provides an instant routing signal for subsequent differential processing.

[0151] Step S702: Determine the parsing mode that matches the current slice data frame based on the value of the type indicator field;

[0152] The first value corresponds to the first parsing mode, and the second value corresponds to the second parsing mode.

[0153] Specifically, the first parsing mode corresponds to the critical slice encapsulation strategy of the sending end, which means that the slice contains frame header information and requires complex parsing logic to extract key metadata such as frame header offset value; the second parsing mode corresponds to the ordinary slice encapsulation strategy, which only needs to extract basic information such as slice count value.

[0154] Understandably, this binary mapping mechanism allows the receiver to function like a multiplexer, quickly switching to the correct processing channel based on the input signal. For example, in an FPGA implementation, the type indicator can be directly used as input to the state machine to control state transitions: when a "0" is detected, the state machine enters the "critical slice parsing state," activating the entire decoder; when a "1" is detected, it enters the "normal slice parsing state," activating only the slice count decoder. This design avoids invalid parsing, reducing processing latency and resource consumption.

[0155] Step S703: Obtain the encoding overhead fields in the custom extension overhead, excluding the type indicator;

[0156] The encoding overhead field includes the combined data block and the additional checksum;

[0157] In this embodiment, after reading and identifying the type indicator, the receiving end needs to send the remaining binary bits (i.e., the encoding overhead field) to the corresponding decoding module. This field is encoded by forward error correction (FEC) at the sending end and includes the slice count value, frame header offset value (for critical slices), and frame structure count value.

[0158] Specifically, the acquisition process involves truncating the data bus bit width: for example, if the total overhead bit width is 8 bits and the type indicator occupies 1 bit, then the encoded overhead field is the remaining 7 bits. These bit streams are typically latched into a shift register, waiting for the decoding clock to trigger. For example, in the hardware description language (Verilog), this can be achieved through a simple vector slicing operation: coded_overhead = full_overhead[6:0];, thereby passing the clean encoded data to subsequent modules.

[0159] Step S704: Perform forward error correction decoding on the encoding overhead field, use the check code to correct transmission errors and strip the check code to generate the decoded combined data block.

[0160] In particular, since the customized extended overhead is highly susceptible to noise interference and bit flipping in harsh channels, directly parsing the encoded data would lead to serious errors in critical control plane information such as frame header offset values, thereby causing system crashes. Therefore, using the checksum attached at the transmitting end to perform FEC operation on the encoding overhead field can not only detect the presence of bit errors, but also accurately flip the erroneous bits to restore the correct data within the error correction capability. Subsequently, the redundant checksum that has lost its function is stripped away, and the protected and clean combined data block is handed over to the subsequent logic to extract key fields, thereby building a bottom-level security barrier for the reliability of frame synchronization.

[0161] Step S705: When the parsing mode is the first parsing mode, recover the slice count value, frame header offset value and frame structure count value from the decoded combined data block, and update the locally stored frame structure count value.

[0162] Specifically, in the first parsing mode, the receiving end calls a bit-width parsing template that matches the first encapsulation mode (e.g., total bit width N = A + B + C). The decoding logic splits the decoded combined data block into three independent data segments according to the field segmentation rules defined in the template: the first A bits are mapped to the slice count value, the middle B bits are mapped to the frame header offset value, and the last C bits are mapped to the frame structure count value.

[0163] Among them, the restored frame structure count value not only identifies the original data frame to which the current slice belongs, but also is used to compare with the count value saved locally to verify the continuity of the frame. Therefore, the system will update the local register with the newly restored frame structure count value as the reference benchmark for subsequent slice parsing. For example, if the restored frame structure count value is 100 and the locally saved value is 99, it indicates that a frame has ended completely and a new frame has started. The system will then update the local value to 100 to ensure the accuracy of timing tracking.

[0164] It should be noted that after the receiving end is powered on, it enters the search mode, waits to receive the first key slice, restores the frame structure count value from its customized extended overhead to initialize the local cache, and then switches to the normal parsing mode.

[0165] Step S706, when the parsing mode is the second parsing mode, restore the slice count value from the decoded combined data block, configure the frame header offset value to the preset invalid state, and obtain the frame structure count value saved locally as the frame structure count value associated with the current slice data frame.

[0166] Specifically, in the second parsing mode, the receiving end calls a simplified template (total bit width M < A + B + C) that matches the second encapsulation mode. The decoding logic only extracts the first A bits from the decoded combined data block and restores them to the slice count value. Since the ordinary slice does not contain a frame header, the system will force the frame header offset value to be configured to the preset invalid state code (such as a binary number with all 1s) to avoid misreading by the receiving end.

[0167] Moreover, for the frame structure count value, the system no longer decodes it from the current overhead, but directly references the count value saved locally. Because the ordinary slice is part of the current frame being processed, its frame structure count value must be the same as that of the previous key slice. This mechanism ensures that even without explicitly transmitting the frame number, the receiving end can correctly assign all slices to the same data frame through context association. For example, if the frame structure count value saved locally is 100, regardless of the slice count value of the current ordinary slice, the system knows that it belongs to the 100th data frame and thus correctly places it in the recombination buffer of the 100th frame.

[0168] The above implementation achieves a highly adaptive intelligent parsing mechanism. Through type indicator-driven differential decoding, it not only avoids the resource waste caused by full-mode traversal, but also fully recovers frame synchronization navigation information through the first parsing mode and maintains frame continuity by utilizing the local context through the second parsing mode. Thus, it maximizes parsing efficiency while ensuring frame positioning accuracy. At the same time, combined with the frame structure count value update and reuse mechanism, it effectively ensures the timing consistency of slices in complex transmission environments, reduces the processing complexity and latency of the receiver, and provides solid technical support for real-time service reconstruction in high-speed communication systems.

[0169] Reference Figure 8 As one implementation of step S604, the step of locating the start boundary of the frame header of the data frame in the slice data payload of the slice data frame according to the frame header offset value includes:

[0170] Step S801: Obtain the predefined address calculation coefficients, and multiply the frame header offset value by the address calculation coefficients to generate the memory address offset;

[0171] The frame header offset is defined at the sending end as a "relative position within a slice," typically in bytes. However, in the specific hardware implementation at the receiving end, the addressing granularity of the memory address may differ from the unit of the offset, or the mapping relationship from the physical layer to the logical layer may need to be considered.

[0172] Therefore, the system introduces a "predefined address calculation coefficient" as a conversion bridge. For example, if the system memory is byte-addressed and the frame header offset is also in bytes, the coefficient is 1; if the memory is 32-bit word-addressed, the coefficient may be 4 (i.e., 1 offset corresponds to 4 bytes). By multiplying the frame header offset by the coefficient, the system obtains the precise memory address offset, which is a physical address increment that can be directly used for pointer operations. For example, if the frame header offset is 36 and the address calculation coefficient is 1 (byte addressing), the generated memory address offset is 36 bytes, indicating that the receiving end logic jumps 36 bytes forward from the slice start position.

[0173] Step S802: Obtain the starting memory address of the slice data payload of the slice data frame;

[0174] Specifically, at the receiving end, after a sliced ​​data frame is received through the physical layer interface and undergoes deframe processing, its sliced ​​data payload is stored in a specific area of ​​system memory (such as DDR SDRAM or on-chip RAM). The system must first obtain the starting memory address of this storage area, which is usually a physical or virtual address indicating the location of the first byte of the current sliced ​​data payload in memory space. This address is the origin of all subsequent pointer operations. For example, in the soft-core processor of an embedded system or FPGA, this address may be written into a specific register by the memory management unit (MMU) or DMA controller upon completion of reception, for subsequent frame processing modules to read.

[0175] Step S803: Perform an addition operation on the starting memory address and the memory address offset to generate the absolute address of the frame header start boundary;

[0176] The system uses a simple adder to add the starting memory address obtained in the previous step to the memory address offset generated in the previous step. The result is the absolute address of the frame header start boundary, which is no longer a relative value, but a physical address that can be directly used for memory read operations. This direct addressing mechanism completely avoids the cumbersome process of byte-by-byte sliding comparison required in traditional framing methods, simplifying the framing operation to a single arithmetic operation.

[0177] For example, if the starting memory address is 0x80001000 and the memory address offset is 0x24 (36 bytes), then the calculated absolute address is 0x80001024. The receiving end logic can directly initiate a read request to this address to obtain the data at that location.

[0178] Step S804: Read data at the absolute address and obtain the predefined frame header signature.

[0179] The system reads several bytes of data from the specified address via the memory controller (the read length is typically the same as the length of the frame header signature). Simultaneously, the system retrieves a "predefined frame header signature" from the local configuration register or firmware. This signature is a standard frame header identifier for a specific communication protocol; for example, in the OTN standard, it is the byte sequence of the Frame Alignment Signal (FAS) (e.g., 0xF628); in Ethernet, it is the preamble and start-of-frame delimiter (SFD). Retrieving these two pieces of data is a prerequisite for validity checks, ensuring that the system is not blindly locating a potentially erroneous position.

[0180] Step S805: Determine whether the read data conforms to the frame header feature code; if yes, proceed to step S806; otherwise, proceed to step S807.

[0181] Step S806: Generate and output the position identifier of the frame header start boundary;

[0182] Step S807 triggers the error handling process.

[0183] Specifically, the system compares the actual data read with the predefined frame header feature code bit by bit. If the two match perfectly, it proves that the absolute address calculated in the previous step is indeed the starting position of the frame header, and the location is successful. At this time, the system generates a position identifier for the frame header start boundary (which can be a status signal or a message containing address information) and outputs it to the subsequent frame reassembly module, notifying it to start extracting data frames from this point.

[0184] If the comparison fails, it indicates an error in location, which may be due to transmission errors causing incorrect overhead information or corruption of the slice data itself. In this case, the system will not output the location of the error, but will immediately trigger an "error handling process," such as discarding the current slice, reporting an alarm to the upper layer, or requesting the sender to retransmit the slice, thereby ensuring the robustness and reliability of data processing.

[0185] The above implementation achieves hardware-accelerated deterministic frame header localization. By directly calculating the logical offset into the physical memory address, it replaces the time-consuming byte-by-byte search algorithm in traditional software or firmware, thereby completing frame synchronization in nanoseconds. At the same time, combined with a secondary verification mechanism for predefined frame header feature codes, it effectively filters out false localization caused by transmission errors, ensures the accuracy of frame start boundary identification, reduces system processing latency, and improves the overall reliability of data transmission.

[0186] Reference Figure 9 As one implementation of step S605, based on the frame structure count value and combined with the determination result of the located frame header start boundary or skip frame header positioning operation, the continuously received slice data payload is reconstructed into a complete data frame to complete frame synchronization.

[0187] Step S901: Determine the timing order of the slice data load based on the difference between the frame structure count value associated with the current slice and the frame structure count value of the previous slice data load.

[0188] Specifically, when the difference is equal to the preset step threshold, the slice data load is determined to be continuous and the timing order is determined; when the difference is not equal to the preset step threshold, a missing slice retransmission request is triggered, and the current data writing operation is suspended until the retransmitted missing slice data load is received and the timing order is re-determined.

[0189] Specifically, the frame structure count acts as a "sequence number." The system monitors the difference between the count values ​​of the current slice and the previous slice in real time. The preset step threshold is usually set to 1, indicating that the frame number should increase continuously. If the difference is 1, it indicates that the transmission is continuous, the system confirms the timing order of the current slice, and allows it to enter the write queue. If the difference is not 1 (for example, the current value is 100, and the previous slice was 98), it is determined that the slice is lost (the slice of frame number 99 is missing). The system immediately triggers a "missing slice retransmission request" and suspends the current data write operation through the flow control mechanism to prevent incomplete data from being written to memory, causing overwriting or misalignment.

[0190] Step S902: Determine whether a position identifier for the start boundary of the frame header has been generated; if yes, proceed to step S903; if no, proceed to step S904.

[0191] Step S903: Using the address corresponding to the position identifier of the frame header start boundary as the starting memory address, write the continuous slice data loads sequentially into the continuous memory region according to the determined timing order.

[0192] The system first uses the address corresponding to the position identifier of the frame header start boundary as the starting point for writing, which ensures that the first byte of the original data frame is placed in the correct memory location. Subsequently, the system writes the data payload of subsequent slices into the contiguous address space of memory in the order determined in the previous step (determined by the slice count value and the frame structure count value).

[0193] Step S904: Write the current slice data load directly to the next available address in the contiguous memory region where the previous slice data load is located, according to the determined timing sequence.

[0194] Since ordinary slices do not contain frame headers, their absolute write start point cannot be calculated from the frame header offset value like that of critical slices. However, their data is necessarily physically adjacent to the preceding slice in the original frame. Therefore, the system can utilize the established timing order to directly obtain the next available memory address after the previous slice's data has been written as the write start point for the current slice. This design eliminates the need for complex addressing calculations, ensuring seamless splicing of continuous data within the frame in memory while cleverly avoiding write addressing deadlock caused by a lack of offset.

[0195] Step S905: Perform byte alignment at the junction of adjacent slice data payloads to generate a concatenated data block;

[0196] Specifically, byte alignment is crucial during the write process. Because slices may introduce additional byte padding due to encapsulation overhead during transmission, or slice boundaries may not align with memory word boundaries, the system needs to fine-tune at the splice point, removing or compensating for these non-data bytes to ensure that the data load of successive slices is seamlessly connected in memory. For example, if the first slice is written to addresses 0x1000-0x10FF, the system will ensure that the data for the second slice starts writing from address 0x1100, without any overlap or gaps, ultimately generating a large, contiguous block of data.

[0197] Step S906: Obtain a predefined frame structure template, divide the data block into a frame header segment, a payload segment, and a frame trailer segment according to the frame structure template, and reassemble the divided segments according to the standard frame format to generate a complete data frame and complete frame synchronization.

[0198] The system loads a predefined frame structure template, which is dynamically configured based on the communication protocol used by the current service (such as OTN, Ethernet, or SDH). For example, when the protocol is OTN, the frame header length is fixed at 16 bytes; when the protocol is Ethernet, the frame header length can vary from 14 to 22 bytes. This template defines the fixed lengths or delimitation rules for the frame header, payload, and trailer. It is configured and issued by the management plane during system initialization or by adding a protocol type indicator field in the customized extension overhead. The receiving end selects the corresponding frame structure template accordingly.

[0199] In this embodiment, the system logically segments the large data block generated in the previous step according to the template: extracting the first N bytes as the frame header, the middle M bytes as the payload, and the last K bytes as the frame trailer (such as the FCS checksum). Then, the system reassembles these segmented logical segments according to the standard frame format specifications, adding necessary delimiters and padding bytes, ultimately generating a complete data frame that is completely consistent with the sending end and conforms to the protocol specifications. At this point, the receiving end has completed the entire process from receiving the data slice to restoring the service frame, declaring successful frame synchronization.

[0200] In the above implementation, the data frame reconstruction stage achieves accurate restoration from disordered slices to ordered frame structure. Through the continuity verification of frame structure count values ​​and the missing retransmission mechanism, the risk of data interruption caused by network packet loss is effectively eliminated. At the same time, combined with byte alignment operation and protocol-aware frame structure template, the continuity of reconstructed data in physical address and compliance in logical structure are ensured. Thus, while ensuring data integrity, the receiver's adaptive reconstructing capability for heterogeneous services is improved, and finally, highly reliable frame synchronization and service recovery are achieved in high-speed transmission environments.

[0201] The data slicing processing system based on extended overhead to achieve frame synchronization according to the embodiments of this application can implement any of the above methods, and the specific working process of each terminal in the system can refer to the corresponding process in the above method embodiments.

[0202] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and in actual implementation there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0203] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A data slicing processing system for frame synchronization based on extended overhead, characterized in that, The system includes: The sending end is used to parse the acquired raw service data stream, determine the frame header position of the data frame, generate a frame header indicator, and obtain the frame structure count value of the current data frame; segment the data frame according to a preset slice length, generate slice data payloads and slice count values ​​that sequentially number the slice data payloads; determine the frame boundary association attribute and frame header offset value of the current slice data payload according to the frame header indicator; determine the overhead encapsulation mode that matches the current slice data payload according to the frame boundary association attribute, and dynamically combine and map the slice count value, the frame header offset value, and the frame structure count value according to the overhead encapsulation mode to generate a customized extended overhead carrying a type indicator; insert the customized extended overhead into the preset overhead position of the slice data payload, generate a slice data frame with customized extended overhead, and send it; The receiving end is configured to receive slice data frames with customized extended overhead and extract the customized extended overhead; identify the type indicator in the customized extended overhead, determine the parsing mode matching the current slice data frame, and perform differentiated decoding on the customized extended overhead according to the parsing mode to recover the slice count value, and determine the frame header offset value and frame structure count value associated with the current slice; determine whether the frame header offset value is valid; if so, locate the frame header start boundary of the data frame in the slice data payload of the slice data frame according to the frame header offset value; if not, skip the frame header location operation of the current slice data payload; and reconstruct the continuously received slice data payload into a complete data frame according to the frame structure count value and in combination with the located frame header start boundary or the determination result of skipping the frame header location operation, thereby completing frame synchronization.

2. A data slicing processing method based on extended overhead to achieve frame synchronization, characterized in that, Applied to the sending end, the method includes: The acquired raw business data stream is parsed to determine the frame header position of the data frame, generate a frame header indicator, and obtain the frame structure count value of the current data frame. The data frame is segmented according to a preset slice length to generate slice data payloads and slice count values ​​that sequentially number the slice data payloads. The frame boundary association attribute and frame header offset value of the current slice data load are determined based on the frame header indicator. Based on the frame boundary association attribute, an overhead encapsulation mode matching the current slice data load is determined, and the slice count value, the frame header offset value, and the frame structure count value are dynamically combined and mapped according to the overhead encapsulation mode to generate a customized extended overhead carrying a type indicator. The customized extended overhead is inserted into the preset overhead position of the slice data payload to generate a slice data frame with customized extended overhead and then sent.

3. The data slicing processing method for frame synchronization based on extended overhead according to claim 2, characterized in that, The steps of segmenting the data frame according to a preset slice length, generating slice data payloads, and sequentially numbering slice count values ​​for the slice data payloads include: Configure a slice counter and segment the data frame according to the preset slice length to generate the current slice data load; Obtain the current count value of the slice counter, assign the current count value to the current slice data load as the corresponding slice count value, and perform an increment operation on the slice counter; The current slice data load and the corresponding slice count value are associated and stored in the cache queue, and the uncut part of the data frame is further segmented until the data frame is completely segmented, generating all slice data loads and corresponding slice count values.

4. The data slicing processing method for frame synchronization based on extended overhead according to claim 2, characterized in that, The steps for determining the frame boundary association attributes and frame header offset values ​​of the current slice data payload based on the frame header indicator include: Obtain the frame header indicator corresponding to the current slice data payload, and determine the address range of the current slice data payload in the data frame; Determine whether the frame header position corresponding to the frame header indicator is within the address range; If so, the frame boundary association attribute of the current slice data load is marked as a key slice type, and the frame header offset value is calculated and generated based on the frame header position and the starting position of the address range. If not, the frame boundary association attribute of the current slice data load is marked as a normal slice type, and the frame header offset value is configured to a preset invalid status code.

5. The data slicing processing method for frame synchronization based on extended overhead according to claim 4, characterized in that, The steps of determining an overhead encapsulation mode that matches the current slice data load based on the frame boundary association attribute, and dynamically combining and mapping the slice count value, the frame header offset value, and the frame structure count value according to the overhead encapsulation mode to generate a custom extended overhead carrying a type indicator include: Get the frame boundary association attribute of the current slice data load, as well as the slice count value, frame header offset value and frame structure count value corresponding to the current slice data load; Based on the frame boundary association attribute, an overhead encapsulation mode that matches the current slice data load is determined as the target encapsulation mode; wherein, when the frame boundary association attribute is a critical slice type, the target encapsulation mode is determined as the first mode, and when the frame boundary association attribute is a normal slice type, the target encapsulation mode is determined as the second mode. According to the field mapping rules defined in the target encapsulation mode, the slice count value, the frame header offset value, and the frame structure count value are dynamically combined and mapped to generate a combined data block; wherein, when the target encapsulation mode is the first mode, the slice count value, the frame header offset value, and the frame structure count value are mapped and combined into the combined data block; when the target encapsulation mode is the second mode, only the slice count value and the frame structure count value are mapped and combined into the combined data block; The combined data block is forward-corrected and encoded to generate a check code, and the check code is appended to the combined data block to generate an encoded overhead field. Generate the corresponding type indicator field according to the target encapsulation pattern; The type indicator field is concatenated with the encoded overhead field to generate the custom extended overhead.

6. The data slicing processing method for frame synchronization based on extended overhead according to claim 2, characterized in that, Before parsing the acquired raw business data stream, the process also includes: Obtain the current network channel quality index data, and extract the bit error rate and channel load rate values ​​from the quality index data; Based on the bit error rate value and the channel load rate value, calculate the overhead optimization coefficient; The cost optimization coefficient is compared with a predefined first threshold and a second threshold, respectively, and a dynamic cost adjustment parameter is generated based on the comparison result. Specifically, when the cost optimization coefficient is lower than the first threshold, a first adjustment parameter representing a cost simplification strategy is generated; when the cost optimization coefficient is higher than the second threshold, a second adjustment parameter representing a complete cost strategy is generated; and when the cost optimization coefficient is between the first threshold and the second threshold, a third adjustment parameter representing a balanced cost strategy is generated. Based on the dynamic overhead adjustment parameters, verification code configuration parameters and field mapping configuration parameters are generated; wherein, based on the first adjustment parameter, field mapping configuration parameters corresponding to reduced bit width and verification code configuration parameters corresponding to simplified verification are generated; based on the second adjustment parameter, field mapping configuration parameters corresponding to extended bit width and verification code configuration parameters corresponding to enhanced verification are generated; and based on the third adjustment parameter, field mapping configuration parameters corresponding to standard bit width and verification code configuration parameters corresponding to standard verification are generated. The verification encoding configuration parameters and the field mapping configuration parameters are stored in the configuration register so that when the slice count value, the frame header offset value and the frame structure count value are dynamically combined and mapped according to the overhead encapsulation mode, the field mapping configuration parameters are called to determine the mapping bit width, and the verification encoding configuration parameters are called to determine the verification mode type when performing forward error correction encoding on the combined data block.

7. A data slicing processing method based on extended overhead to achieve frame synchronization, characterized in that, Applied to the receiving end, the method includes: Receive slice data frames with custom extended overhead and extract the custom extended overhead; wherein, the custom extended overhead is an overhead carrying a type indicator generated by the sender determining a matching overhead encapsulation mode based on the frame boundary association attribute of the current slice data payload, and dynamically combining and mapping the slice count value, frame header offset value and frame structure count value according to the overhead encapsulation mode. Identify the type indicator in the customized extended overhead, determine the parsing mode that matches the current slice data frame, and perform differential decoding on the customized extended overhead according to the parsing mode to recover the slice count value, and determine the frame header offset value and frame structure count value associated with the current slice; Determine whether the frame header offset value is valid; if yes, locate the frame header start boundary of the data frame in the slice data payload of the slice data frame according to the frame header offset value; if no, skip the frame header positioning operation of the current slice data payload. Based on the frame structure count value and the determination result of the frame header start boundary or skip frame header positioning operation, the continuously received slice data payload is reconstructed into a complete data frame to complete frame synchronization.

8. The data slicing processing method for frame synchronization based on extended overhead according to claim 7, characterized in that, The steps of identifying the type indicator in the customized extended overhead, determining the parsing mode matching the current slice data frame, performing differential decoding on the customized extended overhead according to the parsing mode to recover the slice count value, and determining the frame header offset value and frame structure count value associated with the current slice include: Read the type indicator field from the custom extension overhead; Based on the value of the type indicator field, determine the parsing mode that matches the current slice data frame; wherein the first value corresponds to the first parsing mode, and the second value corresponds to the second parsing mode; Obtain the encoding overhead field from the customized extended overhead, excluding the type indicator; wherein the encoding overhead field includes the combined data block and the additional checksum; The encoding overhead field is subjected to forward error correction decoding. The transmission error is corrected and the check code is stripped to generate the decoded combined data block. When the parsing mode is the first parsing mode, the slice count value, frame header offset value and frame structure count value are recovered from the decoded combined data block, and the locally stored frame structure count value is updated. When the parsing mode is the second parsing mode, the slice count value is recovered from the decoded combined data block, the frame header offset value is configured to a preset invalid state, and the locally stored frame structure count value is obtained as the frame structure count value associated with the current slice data frame.

9. A data slicing processing method for frame synchronization based on extended overhead according to claim 7, characterized in that, The step of locating the start boundary of the frame header of the data frame in the slice data payload of the slice data frame based on the frame header offset value includes: Obtain a predefined address calculation coefficient, and multiply the frame header offset value by the address calculation coefficient to generate a memory address offset; Obtain the starting memory address of the slice data payload of the slice data frame; The starting memory address and the memory address offset are added together to generate the absolute address of the frame header start boundary; Read data at the absolute address and obtain the predefined frame header signature. Determine whether the read data conforms to the frame header feature code; If yes, then generate and output the position identifier of the frame header start boundary; if no, then trigger the error handling process.

10. A data slicing processing method for frame synchronization based on extended overhead according to claim 9, characterized in that, Based on the frame structure count value and combined with the determination result of the located frame header start boundary or skip frame header positioning operation, the continuously received slice data payload is reconstructed into a complete data frame to complete frame synchronization. The steps include: The timing order of the slice data load is determined based on the difference between the frame structure count value associated with the current slice and the frame structure count value of the previous slice data load. Specifically, when the difference equals a preset step threshold, the slice data loads are considered continuous, and the timing order is determined. When the difference does not equal the preset step threshold, a missing slice retransmission request is triggered, and the current data write operation is suspended until the retransmitted missing slice data load is received, after which the timing order is re-determined. Determine whether to generate the position identifier for the frame header start boundary; If so, the address corresponding to the position identifier of the frame header start boundary is used as the starting memory address, and the continuous slice data load is written into the continuous memory area in the determined timing order. If not, the current slice data load is directly written to the next available address in the contiguous memory region where the previous slice data load is located, according to the determined timing sequence. Perform byte alignment at the junction of adjacent slice data payloads to generate the concatenated data block; Obtain a predefined frame structure template, divide the data block into a frame header segment, a frame payload segment, and a frame trailer segment according to the frame structure template, and reassemble the segmented segments according to the standard frame format to generate a complete data frame and complete frame synchronization.

Images