Protocol data unit encapsulation method and device, equipment and storage medium

Abstract

The invention discloses a protocol data unit encapsulation method and device, equipment and a storage medium. The method comprises the following steps: acquiring a to-be-packaged target protocol data unit, and calculating a target load length of the target protocol data unit; calculating the available load length of a first physical frame to be filled, and calculating the residual load length of the first physical frame according to the available load length; and under the condition that the target protocol data unit is the first signaling type data and the target load length is greater than the residual load length, packaging the target protocol data unit in a second physical frame in a non-segmented manner. According to the scheme, through a dynamic pre-judgment mechanism of a target physical frame load space, atomization packaging control over a time sequence sensitive protocol data unit is achieved, reference time slot ambiguity caused by splitting of signaling at the boundary of a physical frame is prevented, therefore, time sequence consistency of key control information in a heterogeneous satellite communication system is guaranteed, and the service life of the heterogeneous satellite communication system is prolonged. And the link stability of the satellite-ground fusion system is effectively improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a protocol data unit encapsulation method, apparatus, device and storage medium. Background Technology

[0002] In the space-ground converged communication system of "downlink DVB-S2 (Digital Video Broadcasting-Satellite-Second Generation) + uplink 5G NR (5G New Radio)," due to the fundamental differences between the two standards in physical layer transmission structure, encapsulation strategy, and timing control mechanism, the system faces prominent cross-standard conflicts in the encapsulation consistency of downlink key signaling and the construction of uplink scheduling time reference.

[0003] At the data structure level, DVB-S2 uses Generic Stream Encapsulation (GSE) to construct its physical frames. To accommodate fixed-length physical frame payloads, GSE supports fragmenting upper-layer protocol data units, allowing a single data packet to be carried across consecutive physical frames in multiple fragments. While this encapsulation strategy improves physical frame utilization, its cross-frame slicing characteristic decouples protocol data boundaries from transmission timing. When a MAC (Media Access Control) protocol data unit carrying UL-DCI (Uplink Downlink Control Information) is segmented by GSE, the preceding fragment may be located in the preceding physical frame, and the following fragment may be located in the following physical frame. This causes the terminal to be unable to confirm the physical frame boundary corresponding to the reference time slot when parsing scheduling instructions. The timing ambiguity introduced by this type of cross-frame slicing disrupts the uplink scheduling time derivation chain, preventing the terminal from determining the correct location of uplink transmission timing. This leads to scheduling timing mismatches, uplink conflicts, or abnormal data transmission, severely impacting the scheduling capabilities of the converged network and the stability of the uplink. Summary of the Invention

[0004] This application provides a protocol data unit encapsulation method, apparatus, device, and storage medium. By introducing an encapsulation decision mechanism based on physical frame residual payload prediction and a timing-consistent key signaling atomic encapsulation strategy, it achieves boundary preservation, timing correlation preservation, and controllable encapsulation behavior of protocol data units in cross-standard downlink bearer links. This method can maintain the unsegmented encapsulation of key control signaling in scenarios such as joint satellite broadcasting and terrestrial mobile communication, time-sensitive key control signaling, dynamic changes in service load, or tight physical frame payload, thereby improving the reliability of uplink scheduling links. It is applicable to complex systems such as satellite-terrestrial converged networks, satellite internet access, multi-mode satellite terminals, and cross-protocol stack collaborative scheduling.

[0005] In a first aspect, this application provides a protocol data unit encapsulation method, applied to a base station, comprising:

[0006] Obtain the target protocol data unit to be encapsulated, and calculate the target payload length of the target protocol data unit; Calculate the available payload length of the first physical frame to be filled, and calculate the remaining payload length of the first physical frame based on the available payload length; When the target protocol data unit is of the first signaling type and the target payload length is greater than the remaining payload length, the target protocol data unit is encapsulated in a second physical frame without segmentation. The second physical frame is a physical frame located after the first physical frame in the transmission sequence.

[0007] Secondly, this application provides a protocol data unit encapsulation device, applied to a base station, comprising: The target payload module is configured to acquire the target protocol data unit to be encapsulated and calculate the target payload length of the target protocol data unit. The remaining payload module is configured to calculate the available payload length of the first physical frame to be filled, and calculate the remaining payload length of the first physical frame based on the available payload length. The first encapsulation module is configured to encapsulate the target protocol data unit into a second physical frame without segmentation when the target protocol data unit is a first signaling type data and the target payload length is greater than the remaining payload length. The second physical frame is a physical frame located after the first physical frame in the transmission sequence.

[0008] Thirdly, this application provides a protocol data unit encapsulation device, comprising: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the protocol data unit encapsulation method as described in the first aspect.

[0009] Fourthly, this application provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the protocol data unit encapsulation method as described in the first aspect.

[0010] This application constructs a protocol data unit encapsulation method based on physical layer payload capacity assessment and signaling type adaptive encapsulation control. This method achieves refined filling strategy selection for target protocol data units, cross-physical frame scheduling decisions, and avoids the increased parsing complexity caused by segmentation. The method first obtains the target protocol data unit to be encapsulated and calculates its target payload length to quantify its resource requirements during the physical layer encapsulation process. Then, it calculates the available payload length of the first physical frame to be filled and further determines the remaining payload length of the first physical frame in the current scheduling cycle based on the available payload length. This constructs a transparent payload capacity view at the physical layer, providing constraints for subsequent encapsulation decisions. When the target protocol data unit belongs to the first signaling type and its target payload length is greater than the remaining payload length of the first physical frame, the system triggers cross-physical frame encapsulation control logic, encapsulating the protocol data unit entirely in the second physical frame without any segmentation. By introducing a signaling type-based encapsulation protection mechanism, this method can ensure the complete one-time transmission of critical control signaling while avoiding the reassembly overhead, decoding discontinuity, and control timing drift risks associated with traditional segmented encapsulation methods. Attached Figure Description

[0011] Figure 1 This is a flowchart of a protocol data unit encapsulation method provided in an embodiment of this application; Figure 2 This is a flowchart of a method for determining the remaining load length provided in an embodiment of this application; Figure 3 This is a flowchart of a method for calculating the remaining load length provided in an embodiment of this application; Figure 4 This is a flowchart of a non-segmented encapsulation method provided in an embodiment of this application; Figure 5 This is a flowchart of a second signaling type data encapsulation method provided in an embodiment of this application; Figure 6 This is a flowchart illustrating the steps of a protocol data unit encapsulation method provided in an embodiment of this application; Figure 7 This is a structural block diagram of a protocol data unit encapsulation device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a protocol data unit encapsulation device provided in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as being processed sequentially, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. A process can be terminated when its operation is completed, but it may also have additional steps not included in the drawings. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

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

[0014] Currently, with the continuous evolution of space-ground converged networks, satellite internet, and 5G / 6G communication technologies, heterogeneous space-ground integrated communication systems exhibit significant differences in link organization models, protocol layer divisions, and service scheduling mechanisms. In the space-ground converged architecture adopting "downlink DVB-S2 + uplink 5G NR," the ground-side base station performs 5G NR uplink data scheduling at the MAC layer, while the satellite-side physical layer handles the transmission of DVB-S2 broadcast signals. The two are fundamentally inconsistent in data encapsulation methods, timing definitions, and addressing structures. Since the two types of links operate based on independent PHY / MAC design concepts, ensuring the consistency of scheduling information, the traceability of timing, and the determinism of terminal behavior in cross-standard environments has become a core challenge in current system design.

[0015] From the perspective of downlink data transport, DVB-S2 adopts a general stream encapsulation protocol, and its physical frames have a fixed payload capacity. To fully utilize the physical layer payload, GSE supports slicing upper-layer data packets, allowing slices of a single MAC PDU to be filled and transmitted across multiple physical frames. This segmented encapsulation mechanism is beneficial for improving spectrum utilization in traditional broadcast services, but it can disrupt the boundary consistency of data units when carrying data with cross-layer control semantics. In contrast, the 5G NR uplink scheduling process is strictly time-sensitive. After receiving the uplink scheduling command from the base station, the terminal needs to deduce the target transmission time based on the timing relationship specified by the standard. This timing link requires that the delivery of UL-DCI must have physical frame-level accuracy and time reference consistency; any cross-frame uncertainty will directly lead to errors in the transmission time slot derivation. In a satellite-ground converged system, if the MAC PDU carrying UL-DCI is sliced ​​by GSE and distributed across consecutive DVB-S2 physical frames, the terminal cannot determine whether its corresponding reference time is based on "frame N" or "frame N+1" before recovering the complete MAC PDU. The timing ambiguity introduced by slicing makes it impossible for the terminal to establish an accurate scheduling starting point, which in turn causes an offset when performing time slot calculation, resulting in uplink transmission timing errors, scheduling failures, or even interference.

[0016] Therefore, this invention aims to propose a protocol data unit encapsulation method that can achieve capacity identification, encapsulation decision-making, and integrity assurance for critical control protocol data units in a communication environment where the base station undertakes downlink broadcast data transmission and concurrent scheduling of multiple types of services. This method obtains the target protocol data unit to be encapsulated and calculates the target payload length, enabling the system to have a quantitative understanding of data resource requirements before encapsulation. Simultaneously, by calculating the available payload length of the first physical frame and determining its remaining payload length, a real-time payload capacity view of the base station's physical layer is constructed, providing an accurate basis for encapsulation strategy selection. When the target protocol data unit belongs to the first signaling type and its target payload length exceeds the remaining payload length of the first physical frame, the system adopts a cross-frame encapsulation control strategy to completely encapsulate the protocol data unit in the second physical frame, thereby avoiding control signaling boundary destruction, reassembly delay, or timing offset problems caused by slicing or segmented transmission. Relying on this signaling type-based encapsulation protection mechanism, this method can ensure that critical control protocol data units obtain a one-time, complete encapsulation path at the physical layer, improving their resolvability and the determinism of scheduling timing.

[0017] Figure 1 This is a flowchart illustrating a protocol data unit encapsulation method provided in an embodiment of this application. (Reference) Figure 1 The terminal device protocol data unit encapsulation method specifically includes: S110. Obtain the target protocol data unit to be encapsulated, and calculate the target payload length of the target protocol data unit.

[0018] In some embodiments, the target protocol data unit can be an upper-layer service data unit to be encapsulated and transmitted through the link layer and physical layer. The target payload length can be the effective bit length or byte length of the target protocol data unit without the link layer header field, check field, and alignment padding field, used to drive subsequent bit loading, encoding parameter selection, and resource allocation processes. The target protocol data unit can correspond to different upper-layer protocol types, such as IP packets, Ethernet data frames, or dedicated message structures for specific services. The target payload length is represented by a uniform length metric across different protocol types.

[0019] In one embodiment, the method for obtaining the target protocol data unit may be as follows: read the data unit to be transmitted from the transmit buffer of the upper protocol stack, load the header field, payload field and tail control field of the data unit into the protocol data unit buffer, and after reading, register the buffer as the target protocol data unit to be encapsulated.

[0020] In one embodiment, the target payload length can be calculated as follows: Length statistics are performed on the complete data area of ​​the target protocol data unit; the number of effective bytes participating in the link layer transport is accumulated to form the original length value; in scenarios with alignment requirements or fixed block size requirements, the original length value is rounded up or padded to obtain the target payload length that satisfies the link layer encapsulation constraints. The target payload length can be expressed in the form of bytes, bits, or the number of coded blocks, and a one-to-one correspondence is established with the subsequent link layer encapsulation unit length, encoding parameter selection, and resource allocation parameters.

[0021] By taking the above steps, the target protocol data unit is acquired and the target payload length is accurately calculated before entering the link layer encapsulation. This allows the subsequent encapsulation process to be executed under clear length constraints, improving the controllability and reliability of the mapping of protocol data units between the link layer and the physical layer.

[0022] S120. Calculate the available payload length of the first physical frame to be filled, and calculate the remaining payload length of the first physical frame based on the available payload length.

[0023] In some embodiments, the available payload length can be a length parameter indicating the effective bearer capacity of the first physical frame after deducting the frame header field, modulation and coding overhead, check field, and necessary alignment bits. This length reflects the maximum range of data bits that the physical frame can load under the current modulation depth, coding scheme, and frame structure configuration, and is used for subsequent protocol data unit loading and padding control.

[0024] In one embodiment, the available payload length can be calculated as follows: perform length parsing on the overall frame structure of the first physical frame, extract the frame header length, coding overhead length, forward error correction redundancy length and tail check length, perform difference operation on these lengths and the total length of the physical frame to obtain the effective bit range that can be used to load service data or protocol data units, and the length of this range is the available payload length.

[0025] In one embodiment, the remaining payload length can be calculated as follows: using the available payload length as the initial capacity, deducting the length of the target protocol data unit already written into the payload area, the length of the link layer control field, and the necessary alignment padding length, and using the deducted value as the remaining payload length of the first physical frame. The remaining payload length reflects the bit space that the current physical frame can continue to accommodate, and is used to determine whether padding bits are needed, whether a new physical frame needs to be started, or whether a segmentation encapsulation strategy needs to be executed.

[0026] Through the above steps, the available payload capacity of the first physical frame is calculated and the remaining available space is obtained in real time, so that subsequent encapsulation operations can be performed under the condition of clear capacity constraints and accurate space allocation, thereby ensuring that the protocol data unit is carried in the physical frame stably, continuously and without structural conflicts.

[0027] Optionally, Figure 2 This is a flowchart illustrating a method for determining the remaining load length provided in an embodiment of this application. (Reference) Figure 2 The method for determining the remaining load length specifically includes: S1201. Obtain the used payload length of the protocol data unit encapsulated in the first physical frame.

[0028] For example, the used payload length can be a length parameter indicating the number of bits or bytes written into the payload area of ​​the first physical frame, reflecting the occupancy status of the current frame in the encapsulation process. This parameter is continuously updated during encapsulation to drive the calculation of remaining space, payload write determination, and the execution of cross-frame encapsulation strategies.

[0029] In one embodiment, the used payload length can be obtained by reading the payload write pointer position of the first physical frame and using the distance between the pointer position and the payload start position as the used payload length of the currently written payload.

[0030] Through the above steps, the used payload length of the first physical frame can be known in real time, so that the subsequent calculation of the remaining payload length, payload writing judgment and physical frame switching operation can be performed under the accurate capacity state, thereby ensuring the continuity of the physical frame encapsulation process and the structural security.

[0031] S1202. The remaining load length is calculated based on the available load length and the used load length.

[0032] For example, the remaining payload length can be a capacity parameter that indicates the number of data bits or bytes that can still be loaded into the first physical frame, used to determine whether new protocol data units can continue to be written during the encapsulation process.

[0033] In one embodiment, the remaining payload length can be calculated by taking the available payload length as the maximum carry-through capacity of the physical frame and the used payload length as the current actual occupancy, and performing a difference operation on the two to obtain the remaining payload length of the physical frame.

[0034] By taking the above steps, the remaining payload length of the first physical frame is obtained, which ensures the continuity and accuracy of the entire encapsulation link in capacity judgment, space allocation and cross-frame encapsulation decision-making, thereby ensuring that the protocol data unit loading process is stable, controllable and does not cause payload overrun.

[0035] Optionally, Figure 3 This is a flowchart illustrating a method for calculating the remaining load length provided in an embodiment of this application. (Reference) Figure 3 The method for calculating the remaining load length specifically includes: S12021. Calculate the first length of the fragment control field and the second length of the length field in the GSE encapsulation header.

[0036] For example, the GSE encapsulation header can consist of a fragment control field, a length field, an identifier field, and other optional extended fields. The fragment control field describes the position of the current data fragment within the complete protocol data unit, and the length field describes the byte length of the subsequent payload portion. To perform the correct encapsulation operation, the first length of the fragment control field and the second length of the length field must first be determined so that the encapsulation module can accurately construct the GSE header structure.

[0037] In one embodiment, the first length can be calculated by: reading the fragment control identifier configuration of the GSE protocol, determining the fragment type attribute of the current data fragment, such as the first fragment, middle fragment, or end fragment, and extracting the corresponding number of control flag bits, which is used as the first length of the fragment control field.

[0038] In one embodiment, the second length can be calculated by reading the fixed or variable number of bits configuration of the length field in the GSE encapsulation rules, and combining it with the payload size corresponding to the current fragment to determine the number of bits required to represent the payload length, which is the second length of the length field.

[0039] By taking the above steps, the first length of the fragment control field and the second length of the length field are obtained, so that the subsequent GSE header generation can be performed under the condition that the field length is clear, thereby ensuring the integrity, stability and protocol consistency of the GSE encapsulation structure.

[0040] S12022. Calculate the head length of the GSE package head based on the first length and the second length.

[0041] For example, the header length of the GSE encapsulation header can be a length parameter used to indicate the proportion of the fragment control field, length field, and necessary alignment bits in the header region, thereby specifying the bit boundary positions of the GSE header during the encapsulation process.

[0042] In one embodiment, the header length can be calculated by superimposing the first length of the fragment control field and the second length of the length field, so that the total number of bits of the two fields forms the header length of the GSE encapsulation header.

[0043] By following the steps above, the complete header length of the GSE package header is obtained, ensuring that the GSE cell has clear bit boundaries during construction and guaranteeing that the header writing process is stable, controllable, and conforms to the protocol structure requirements.

[0044] S12023. The remaining load length is calculated based on the available load length, the used load length, and the head length.

[0045] For example, the remaining payload length can be a capacity parameter indicating the number of data bits or bytes that can still be loaded into the first physical frame, used to determine whether new protocol data units can be written during the encapsulation process. In one embodiment, the remaining payload length can be calculated as follows: the available payload length is taken as the maximum capacity that the first physical frame can carry, the used payload length is taken as the current encapsulation occupancy, and the header length is taken as the additional occupancy required for this write operation. The three lengths are superimposed and interpolated to form a new remaining payload length.

[0046] By taking the above steps, the latest remaining payload length after writing the GSE header is obtained, so that subsequent GSE payload writing, physical frame switching and segmented packaging actions can be performed within the accurate capacity boundary, thereby ensuring the structural correctness and capacity consistency of the entire GSE packaging process.

[0047] S130. When the target protocol data unit is a first signaling type data and the target payload length is greater than the remaining payload length, the target protocol data unit is encapsulated in a second physical frame without segmentation. The second physical frame is a physical frame located after the first physical frame in the transmission sequence.

[0048] In some embodiments, the first signaling type data may be a type of protocol data unit that is latency-sensitive, has high integrity requirements, or is not allowed to be transmitted in segments. It is typically treated as an atomic service payload at the link layer or physical layer and must be written into the physical frame in its complete structure. Such data is not allowed to be split into multiple segmented payloads during the encapsulation process to prevent reassembly failures, parsing errors, or timing drifts during cross-frame transmission.

[0049] In one embodiment, when the target protocol data unit is identified as first signaling type data and the target payload length exceeds the remaining payload length of the first physical frame, the encapsulation module executes a non-segmented encapsulation strategy. That is, it abandons writing the data unit into the remaining space of the current physical frame, and instead directly writes the entire target protocol data unit into the payload area of ​​the second physical frame. The payload area of ​​the second physical frame is empty before encapsulation, and can completely accommodate the entire content of the target protocol data unit, thus meeting the structural requirements of non-segmented encapsulation.

[0050] In one embodiment, the non-segmented encapsulation method can be: creating an encapsulation context for the second physical frame, initializing the payload pointer of the second physical frame, writing the full-length bit sequence of the target protocol data unit into the payload area of ​​the second physical frame, and updating the payload boundary position of the second physical frame after writing is completed, so that the second physical frame can enter the subsequent encoding, modulation and transmission processing link.

[0051] Through the above steps, the first signaling type data can be encapsulated in a new physical frame with a complete structure when the payload space is insufficient, so that the encapsulation process maintains determinism and consistency, and avoids the risk of data reorganization or business timing disruption caused by segmented writing.

[0052] Optionally, Figure 4 This is a flowchart of a non-segmented encapsulation method provided in an embodiment of this application. (Reference) Figure 4 The non-segmented encapsulation method specifically includes: S1301. Fill the remaining payload space of the first physical frame with invalid data.

[0053] For example, invalid data can be a placeholder bit sequence that contains no business semantics and does not participate in the link layer or physical layer parsing process. It is used to fill the remaining payload space of the first physical frame, so that the physical frame maintains its complete bit structure and alignment characteristics after encapsulation. Invalid data usually has a fixed bit pattern, an all-zero pattern, a pseudo-random pattern, or a placeholder format specified by the protocol, and is directly ignored at the receiving end.

[0054] In one embodiment, the action of filling invalid data may be: identifying the remaining payload space range of the first physical frame, using the starting position of the space as a write pointer, and writing the pre-generated invalid data sequence bit by bit into the range, so that the remaining payload area achieves the bit integrity required by the physical frame structure.

[0055] Through the above steps, the remaining payload space of the first physical frame is stably filled, so that the physical frame forms a complete payload range in structure, providing continuous bit input for subsequent forward error correction coding, bit interleaving and modulation operations, and ensuring the integrity and resolvability of the physical frame transmission process.

[0056] S1302. Generate a second physical frame and encapsulate the target protocol data unit in the second physical frame.

[0057] For example, the second physical frame can be a physical frame structure that is in an unloaded state and has not yet been written with any service data or control fields. Its frame header area, payload area, and checksum area are all in an initial state and can be used as a new bearer unit to write complete target protocol data units. The creation of the second physical frame can avoid payload residue and bit alignment errors, allowing the encapsulation process to start again in the new frame structure.

[0058] In one embodiment, the second physical frame can be generated by: initializing a set of frame-level structure parameters for constructing the physical frame, including frame header length, payload capacity, check field length and modulation coding scheme, and writing the initialized structure into the physical frame construction buffer to obtain the second physical frame.

[0059] In one embodiment, the method of encapsulating the target protocol data unit in the second physical frame can be: writing the bit sequence of the target protocol data unit into the starting position of the payload area of ​​the second physical frame, and performing the writing action in a bit-continuous manner so that the data forms a continuous payload segment in the physical frame.

[0060] Through the above steps, the second physical frame is created, and the target protocol data unit is encapsulated in the new physical frame with a complete structure, ensuring that the encapsulation process is performed under conditions of sufficient space and a well-defined structure. This operation avoids risks such as cross-frame segmentation, payload truncation, or alignment offset, ensuring that the target protocol data unit maintains its integrity and resolvability during physical layer transmission.

[0061] Optionally, after calculating the remaining payload length of the first physical frame based on the available payload length, the method further includes: When the target protocol data unit is a first signaling type data and the target payload length is less than or equal to the remaining payload length, the target protocol data unit is encapsulated in the first physical frame.

[0062] For example, when the target protocol data unit belongs to the first signaling type data and the target payload length is less than or equal to the remaining payload length of the first physical frame, the encapsulation module can directly write the target protocol data unit into the payload area of ​​the first physical frame, so that the data unit participates in the transmission process of the current physical frame with a complete structure.

[0063] In one embodiment, the encapsulation method may be: writing the bit sequence of the target protocol data unit into the starting position of the remaining payload space of the first physical frame, so that the data occupies the payload area in the form of consecutive bits. After the writing is completed, the payload occupancy mark of the first physical frame is updated so that the new payload boundary position points to the end position of the bit after writing, thereby ensuring that the first physical frame maintains structural integrity in the encoding link.

[0064] Through the above steps, if the payload space allows, the first signaling type data can be directly encapsulated in the first physical frame, so that the data unit can complete the transmission preparation in the current physical frame, ensuring the real-time performance, integrity and controllability of the encapsulation link of the high-priority signaling.

[0065] Optionally, Figure 5 This is a flowchart illustrating a second signaling type data encapsulation method provided in an embodiment of this application. (Reference) Figure 5 The second signaling type data encapsulation method specifically includes: S140. When the target protocol data unit is second signaling type data and the target payload length is greater than the remaining payload length, the target protocol data unit is segmented and encapsulated in the first physical frame and the second physical frame.

[0066] For example, the second signaling type data can be a protocol data unit that allows segmented transmission between physical frames. Its service semantics allow it to be reassembled in multiple fragments, thus enabling it to be written in fragments to different physical frames when payload space is insufficient. Unlike the first signaling type data, which does not allow segmentation, this type of data has cross-frame reassembly capabilities and can indicate fragment position, order attributes, and reassembly relationships through fragment control fields.

[0067] In one embodiment, when a target protocol data unit is identified as second signaling type data and its target payload length is greater than the remaining payload length of the first physical frame, the encapsulation module initiates a segmented encapsulation strategy, causing the target protocol data unit to be split into a first segment and subsequent segments. The first segment is written to the remaining payload area of ​​the first physical frame, and the subsequent segments are written to the second physical frame, enabling the target protocol data unit to be sequentially carried across multiple physical frames.

[0068] Through the above steps, the second signaling type data can be written into the first physical frame and the second physical frame in fragment form under the condition of insufficient load, so that the protocol data unit maintains structural continuity and reconfigurability in cross-frame transmission, ensuring the flexibility of the encapsulation link and the ability to fully recover service data.

[0069] S150, if the target protocol data unit is second signaling type data and the target payload length is less than or equal to the remaining payload length, the target protocol data unit is encapsulated in the first physical frame.

[0070] For example, when the target protocol data unit belongs to the second signaling type data and the target payload length is less than or equal to the remaining payload length of the first physical frame, the data unit can be directly written into the first physical frame in its entirety, so that it does not need to perform cross-frame segmentation operation.

[0071] In one embodiment, the encapsulation action may be: writing the bit sequence of the target protocol data unit into the starting position of the remaining payload space of the first physical frame, so that the data forms a continuous payload segment within the physical frame; the writing operation is completed by maintaining bit order, so that the protocol data unit maintains structural stability in the physical layer and has direct recovery capability.

[0072] Through the above steps, when the payload space meets the conditions for full packet encapsulation, the second signaling type data can be written into the first physical frame with a complete structure, avoiding the reassembly overhead caused by cross-frame segmentation, and enabling the protocol data unit to achieve higher processing efficiency and structural stability in the link layer encapsulation link.

[0073] Optionally, the first signaling type data includes uplink scheduling information, random access response, and time synchronization instruction, and the second signaling type data includes user plane data.

[0074] For example, the first signaling type data can be a protocol data unit used to carry control commands. Its structure typically has high timeliness and content integrity requirements, making cross-frame segmentation unsuitable. The first signaling type data may include uplink scheduling information, random access responses, and time synchronization commands. During transmission, the first signaling type data emphasizes timing accuracy and structural atomicity; therefore, a full-packet encapsulation strategy is prioritized in the encapsulation link. The second signaling type data can be a protocol data unit used to carry service data or user plane data. Its content allows for segmentation across multiple physical frames, and reassembly is completed at the receiving end via a fragment control field. The second signaling type data has high divisibility and a large service load capacity; therefore, when payload space is insufficient, a segmentation encapsulation strategy can be implemented to improve physical frame payload utilization.

[0075] Through the above steps, it is possible to distinguish between non-segmentable control data and segmentable service data in terms of signaling type, so that the two types of data can obtain different transmission strategies in the encapsulation link, thereby ensuring the timeliness of control data and the bandwidth adaptability of service data.

[0076] Optionally, Figure 6 This is a flowchart illustrating the steps of a protocol data unit encapsulation method provided in an embodiment of this application. (Reference) Figure 6 The specific encapsulation method for the protocol data unit includes: S201. Obtain the available load length.

[0077] For example, the available payload length can be a capacity parameter indicating the maximum number of effective bits or bytes that can be written to the current physical frame for service or control data during the protocol encapsulation phase. This capacity parameter is formed after the frame structure, modulation scheme, encoding scheme, and frame header overhead are determined, and is used to constrain the loading range of subsequent protocol data units.

[0078] In one embodiment, the available payload length can be obtained by reading the payload capacity record corresponding to the current physical frame from the frame structure configuration table of the physical layer or link layer, and loading the effective payload bits in the record into the encapsulation control context. This record is typically calculated during system initialization or frame structure changes and stored as a parameter, which the encapsulation module directly retrieves when entering the encapsulation process.

[0079] S202. Calculate the remaining load length.

[0080] For example, the remaining payload length can be an effective capacity parameter used to indicate the current physical frame still available for loading protocol data units after a portion of the payload has been written.

[0081] In one embodiment, the remaining payload length can be calculated as follows: using the available payload length as the total capacity limit of the current physical frame and the used payload length as the current write occupancy, the difference between the two lengths is calculated to obtain the remaining payload length. For example, the formula for calculating the remaining payload length is as follows:

[0082] in, The remaining load length, For the available load length, The length of the packaged PDU. This represents the length occupied by the GSE.

[0083] S203. When the target protocol data unit to be transmitted is first signaling type data, perform disallow segmentation encapsulation.

[0084] For example, prohibiting segmentation encapsulation can be an encapsulation constraint rule for first signaling type data, used to ensure that this type of data is presented in a complete structure within a physical frame, without cross-frame splitting or fragmented transmission. First signaling type data typically has high real-time, high integrity, and strong atomicity requirements, therefore segmentation is prohibited in the encapsulation link.

[0085] In one embodiment, when the target protocol data unit to be sent is identified as first signaling type data, the encapsulation module initiates a segmentation-disallowing encapsulation strategy, directly marking the segmentation logic as non-executable, so that subsequent encapsulation processes only allow whole-packet write operations. Under this strategy, segmentation control fields are not inserted, fragment cutting actions are not triggered, and the encapsulation operation maintains the whole-packet write method. For example, for the next target protocol data unit to be sent, if it is identified as a critical signaling type, the following judgment is performed:

[0086] in, The length of the target protocol data unit to be sent. The number of additional protocol header bits required for the target protocol data unit. This represents the remaining load length.

[0087] If the above formula holds true, it means there is enough space in the current physical frame, and the target protocol data unit can be encapsulated into the current physical frame. If the above formula does not hold true, it means there is insufficient space in the current physical frame, and a padding operation is performed on the current physical frame, using the remaining space in the current frame. The space is filled with GSE Padding packets (S=0, E=0, LT=00), and the target protocol data unit is placed at the beginning of the next physical frame for complete encapsulation.

[0088] S204. If the target protocol data unit to be transmitted is second signaling type data, perform segmentation encapsulation.

[0089] For example, allowing segmented encapsulation can be an encapsulation strategy for second signaling type data, used to split the target protocol data unit into multiple fragments and write them into different physical frames when there is insufficient physical frame payload space. Second signaling type data typically has cross-frame reassembly capability, allowing transmission in multiple segments, thus enabling segmentation operations to be performed in the encapsulation link.

[0090] In one embodiment, when the target protocol data unit to be transmitted is identified as second signaling type data, the encapsulation module activates a segmentation encapsulation strategy, enabling the encapsulation link to perform operations such as fragment splitting, fragment control field insertion, and cross-frame carrying. This strategy allows the encapsulation module to prioritize writing the first segment when payload space is insufficient, and migrate the remaining content to subsequent physical frames. For example, for the next target protocol data unit to be transmitted, if it is identified as a normal data type and the current physical frame has insufficient space, it is segmented according to the standard DVB-S2 GSE protocol, filling the current physical frame with a portion of the target protocol data unit, and placing the remaining portion into the next physical frame.

[0091] Based on the above embodiments, Figure 7 This is a structural block diagram of a protocol data unit encapsulation device provided in an embodiment of this application. (Reference) Figure 7 The protocol data unit encapsulation device provided in this embodiment specifically includes: target payload module 11, remaining payload module 12, and first encapsulation module 13.

[0092] The target payload module 11 is configured to acquire the target protocol data unit to be encapsulated and calculate the target payload length of the target protocol data unit; the remaining payload module 12 is configured to calculate the available payload length of the first physical frame to be filled and calculate the remaining payload length of the first physical frame based on the available payload length; the first encapsulation module 13 is configured to encapsulate the target protocol data unit into a second physical frame without segmentation when the target protocol data unit is a first signaling type data and the target payload length is greater than the remaining payload length, wherein the second physical frame is a physical frame located after the first physical frame in the transmission sequence.

[0093] Based on the above embodiments, the remaining payload module 12 includes: a used payload unit configured to obtain the used payload length of the protocol data units encapsulated in the first physical frame; and a remaining payload unit configured to calculate the remaining payload length based on the available payload length and the used payload length.

[0094] Based on the above embodiments, the remaining load unit includes: a length calculation subunit configured to calculate a first length of the fragment control field and a second length of the length field of the GSE package header; a header length subunit configured to calculate the header length of the GSE package header based on the first length and the second length; and a remaining load subunit configured to calculate the remaining load length based on the available load length, the used load length, and the header length.

[0095] Based on the above embodiments, the protocol data unit encapsulation device further includes: a second encapsulation module, configured to encapsulate the target protocol data unit in the first physical frame when the target protocol data unit is a first signaling type data and the target payload length is less than or equal to the remaining payload length.

[0096] Based on the above embodiments, the protocol data unit encapsulation device further includes: a third encapsulation module configured to encapsulate the target protocol data unit in segments within the first physical frame and the second physical frame when the target protocol data unit is second signaling type data and the target payload length is greater than the remaining payload length; and a fourth encapsulation module configured to encapsulate the target protocol data unit within the first physical frame when the target protocol data unit is second signaling type data and the target payload length is less than or equal to the remaining payload length.

[0097] Based on the above embodiments, the first signaling type data includes uplink scheduling information, random access response, and time synchronization instruction, and the second signaling type data includes user plane data.

[0098] Based on the above embodiments, the first encapsulation module 13 includes: a payload filling unit configured to fill invalid data in the remaining payload space of the first physical frame; and a non-segmented encapsulation unit configured to generate a second physical frame and encapsulate the target protocol data unit in the second physical frame.

[0099] The protocol data unit encapsulation device provided in this application embodiment, by constructing a hierarchical load assessment and adaptive encapsulation processing system composed of a target payload module 11, a remaining payload module 12, and a first encapsulation module 13, achieves dynamic bearer calculation, cross-frame encapsulation decision-making, and adaptive signaling type processing of protocol data units under a multi-physical frame structure, thereby improving the continuity of the encapsulation process, frame-level resource utilization, and service bearer stability. The target payload module 11 has the capability to acquire protocol data units and calculate payloads. It receives the target protocol data unit to be encapsulated, determines the target payload length based on the protocol header field and encapsulation format, and provides benchmark payload information for subsequent physical frame bearer capacity assessment. The remaining payload module 12 undertakes the task of analyzing available physical frame resources. By calculating the available payload length of the first physical frame to be filled, it further obtains the remaining payload length capable of carrying service data, achieving precise quantification of frame-level remaining resources and providing constraint thresholds for encapsulation decisions. The first encapsulation module 13 undertakes the task of adaptive encapsulation control for signaling types. When the target protocol data unit belongs to the first signaling type and the target payload length is greater than the remaining payload length of the first physical frame, the target protocol data unit is encapsulated in a complete format in the second physical frame. This avoids context fragmentation, increased parsing difficulty, or timing discontinuity caused by cross-frame segmentation in signaling services, ensuring the stability and consistency of the signaling processing flow. Through the coordinated acquisition of the payload reference by the target payload module, the frame resource quantization by the remaining payload module, and the cross-frame adaptive control by the first encapsulation module, the device can achieve highly reliable protocol data unit encapsulation under conditions of fluctuating physical frame resources, uneven link occupancy, or changes in signaling priority. This improves the resource scheduling efficiency and service continuity of the system in signaling-intensive or multi-service concurrent communication environments.

[0100] The protocol data unit encapsulation device provided in this application embodiment can be used to execute the protocol data unit encapsulation method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0101] Figure 8 This is a schematic diagram of the structure of a protocol data unit encapsulation device provided in an embodiment of this application, with reference to... Figure 8 The protocol data unit encapsulation device includes a processor 21, a memory 22, a communication device 23, an input device 24, and an output device 25. The number of processors 21 and the number of memories 22 in the protocol data unit encapsulation device can be one or more. The processor 21, memory 22, communication device 23, input device 24, and output device 25 of the protocol data unit encapsulation device can be connected via a bus or other means.

[0102] The memory 22, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the protocol data unit encapsulation method in any embodiment of this application (e.g., the target payload module 11, the remaining payload module 12, and the first encapsulation module 13 in the protocol data unit encapsulation device). The memory 22 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory 22 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0103] The communication device 23 is used for data transmission.

[0104] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, thereby implementing the above-mentioned protocol data unit encapsulation method.

[0105] Input device 24 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the device. Output device 25 may include display devices such as a display screen.

[0106] The protocol data unit encapsulation device provided above can be used to execute the protocol data unit encapsulation method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0107] This application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform a protocol data unit encapsulation method. The protocol data unit encapsulation method includes: obtaining a target protocol data unit to be encapsulated; calculating the target payload length of the target protocol data unit; calculating the available payload length of a first physical frame to be filled; calculating the remaining payload length of the first physical frame based on the available payload length; and, when the target protocol data unit is a first signaling type data and the target payload length is greater than the remaining payload length, encapsulating the target protocol data unit without segmentation in a second physical frame, wherein the second physical frame is a physical frame located after the first physical frame in the transmission sequence.

[0108] Storage medium—any type of memory device or storage device. The term "storage medium" is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which a program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term "storage medium" may include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0109] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the protocol data unit encapsulation method described above, but can also perform related operations in the protocol data unit encapsulation method provided in any embodiment of this application.

[0110] The protocol data unit encapsulation device, storage medium, and protocol data unit encapsulation equipment provided in the above embodiments can execute the protocol data unit encapsulation method provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the protocol data unit encapsulation method provided in any embodiment of this application.

[0111] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application. The scope of this application is determined by the scope of the claims.

Claims

1. A protocol data unit encapsulation method, applied to a base station, characterized in that, include: Obtain the target protocol data unit to be encapsulated, and calculate the target payload length of the target protocol data unit; Calculate the available payload length of the first physical frame to be filled, and calculate the remaining payload length of the first physical frame based on the available payload length; When the target protocol data unit is of the first signaling type and the target payload length is greater than the remaining payload length, the target protocol data unit is encapsulated in a second physical frame without segmentation. The second physical frame is a physical frame located after the first physical frame in the transmission sequence.

2. The protocol data unit encapsulation method according to claim 1, characterized in that, The step of calculating the remaining payload length of the first physical frame based on the available payload length includes: Obtain the used payload length of the protocol data units encapsulated in the first physical frame; The remaining load length is calculated based on the available load length and the used load length.

3. The protocol data unit encapsulation method according to claim 2, characterized in that, The calculation of the remaining load length based on the available load length and the used load length includes: Calculate the first length of the fragment control field and the second length of the length field in the GSE encapsulation header; The head length of the GSE package head is calculated based on the first length and the second length; The remaining load length is calculated based on the available load length, the used load length, and the head length.

4. The protocol data unit encapsulation method according to claim 1, characterized in that, After calculating the remaining payload length of the first physical frame based on the available payload length, the method further includes: When the target protocol data unit is a first signaling type data and the target payload length is less than or equal to the remaining payload length, the target protocol data unit is encapsulated in the first physical frame.

5. The protocol data unit encapsulation method according to claim 1, characterized in that, After calculating the remaining payload length of the first physical frame based on the available payload length, the method further includes: When the target protocol data unit is a second signaling type data and the target payload length is greater than the remaining payload length, the target protocol data unit is segmented and encapsulated in the first physical frame and the second physical frame; When the target protocol data unit is second signaling type data and the target payload length is less than or equal to the remaining payload length, the target protocol data unit is encapsulated in the first physical frame.

6. The protocol data unit encapsulation method according to claim 5, characterized in that, The first signaling type data includes uplink scheduling information, random access response, and time synchronization instruction, while the second signaling type data includes user plane data.

7. The protocol data unit encapsulation method according to claim 1, characterized in that, The step of encapsulating the target protocol data unit into a second physical frame without segmentation includes: Fill the remaining payload space of the first physical frame with invalid data; A second physical frame is generated, and the target protocol data unit is encapsulated in the second physical frame.

8. A protocol data unit encapsulation device, applied to a base station, characterized in that, include: The target payload module is configured to acquire the target protocol data unit to be encapsulated and calculate the target payload length of the target protocol data unit. The remaining payload module is configured to calculate the available payload length of the first physical frame to be filled, and calculate the remaining payload length of the first physical frame based on the available payload length. The first encapsulation module is configured to encapsulate the target protocol data unit into a second physical frame without segmentation when the target protocol data unit is a first signaling type data and the target payload length is greater than the remaining payload length. The second physical frame is a physical frame located after the first physical frame in the transmission sequence.

9. A protocol data unit encapsulation device, characterized in that, include: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the protocol data unit encapsulation method as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the protocol data unit encapsulation method as described in any one of claims 1-7.

Images