Adaptive protocol stack reconstruction and transaction-level data control method for 5G communication

Abstract

The invention discloses an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication, and aims to solve the technical problems of fixed protocol stack structure, coarse transmission control granularity and the like of an existing communication module. The method comprises the following steps: firstly, analyzing an application layer communication session initialization instruction, generating a communication task label, acquiring 5G network environment state data in real time, and constructing a network state feature vector; then, the communication task label and the network state feature vector are input into a protocol mapping decision map, a protocol reconstruction instruction is generated, loading and unloading of a protocol module in a protocol stack resource pool are controlled, a dynamically-adaptive protocol path is constructed, and a transaction identifier is allocated to the protocol path; and establishing a transaction-level data buffer area based on the transaction identifier, performing priority marking on the data packet, and executing differentiated dynamic flow control operation according to the network state feature vector and the priority label, thereby realizing high-reliability and low-delay 5G communication data management.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to an adaptive protocol stack reconstruction and transaction-level data control method for 5G communications. Background Art

[0002] In existing technologies, 5G communication modules typically use a communication protocol stack with a preset fixed structure to support data transmission tasks. The loaded protocol module combinations are mostly based on static configurations and are difficult to dynamically adjust according to specific application scenarios or network status. Common protocol paths such as TCP / IP, QUIC, HTTP / 3, etc., often rely on system initialization settings to enable their modules, lacking flexibility during runtime. At the same time, differentiated control for different service requirements is mainly concentrated in the application layer. The protocol stack itself lacks adaptive capabilities, making it difficult to support the refined management of communication performance in 5G scenarios such as low latency, high reliability, and multi-tasking concurrency.

[0003] However, with the rapid development of high-real-time 5G application scenarios such as the Industrial Internet of Things (IIoT), the Internet of Vehicles (IoV), and remote control, the existing protocol stack architecture has exposed numerous deficiencies in its dynamic adaptability. For one thing, it's impossible to precisely tailor and reconfigure protocol modules based on real-time network conditions, such as channel quality, latency, or congestion. Furthermore, existing data control mechanisms, which are mostly connection- or flow-level, make it difficult to implement transaction-level prioritization and traffic regulation, resulting in difficulties in ensuring the transmission efficiency and reliability of critical business data.

[0004] In view of this, it is necessary to propose a new method to improve the dynamic adaptability of 5G communication modules in protocol processing and data scheduling. Summary of the Invention

[0005] The present application provides an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication to enhance the dynamic adaptability of 5G communication modules in protocol processing and data scheduling.

[0006] The present application provides an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication, including: Parsing the communication session initialization instruction issued by the application layer, extracting parameters related to service type, delay tolerance, and reliability requirements in the communication session initialization instruction, and generating a communication task label based on the parameters; Obtaining status data of the current 5G network environment, the status data including channel quality indicator value, uplink and downlink average delay, available bandwidth and congestion level, and constructing a network status feature vector based on the status data; Inputting the communication task label and the network state feature vector into a protocol mapping decision graph to generate a protocol reconstruction instruction, wherein the protocol reconstruction instruction is used to control the loading and unloading operations of the protocol module in the protocol stack resource pool; According to the protocol reconstruction instruction, at least one protocol module is loaded or unloaded from the protocol stack resource pool to construct a protocol path that meets the requirements of the communication task label and the network state feature vector, and a transaction identifier is assigned to each protocol path; Establishing a transaction-level data buffer based on the transaction identifier, dividing the data to be transmitted into a plurality of data packets and writing the data packets into the transaction-level data buffer, and marking each data packet with a priority tag corresponding to the communication task tag; Dynamic flow control operations are performed according to the network state feature vector and the priority label.

[0007] The beneficial effects of the technical solution provided by this application include: (1) By introducing a joint judgment mechanism of communication task labels and network status feature vectors, the loading and unloading of protocol modules in the protocol stack resource pool can be controlled according to real-time business needs and network conditions, and the dynamic reconstruction of the protocol path can be realized, thereby breaking the limitations of the fixed protocol stack structure in the existing communication module and improving the adaptability and resource utilization efficiency of protocol processing. (2) Each protocol path is assigned an independent transaction identifier, and a transaction-level data buffer is established, which can perform transaction granularity management and isolation of data packets during data transmission, avoid mutual interference between data flows between different communication tasks, and improve the stability and controllability of data processing in a multi-task concurrent environment. (3) By marking each data packet with a priority label corresponding to the communication task label in the transaction-level data buffer, the system can distinguish scheduling strategies according to the importance of the task, giving priority to ensuring the timely and reliable transmission of critical data in a complex network environment. It is suitable for scenarios with high requirements for real-time performance and reliability, such as industrial control and telemedicine. (4) Dynamic flow control operations are driven by network status feature vectors and priority tags. They can adjust the sending window size, optimize the scheduling order, and perform selective retransmission in real time, thereby maintaining efficient and stable data transmission capabilities in the event of bandwidth fluctuations or network congestion, significantly enhancing the robustness of the system in complex network environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 This is a flowchart of an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication provided in the first embodiment of the present application. DETAILED DESCRIPTION

[0009] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of the present application. Therefore, the present application is not limited to the specific implementations disclosed below.

[0010] The first embodiment of the present application provides an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication. Figure 1 , which is a schematic diagram of the first embodiment of this application. Figure 1 The first embodiment of the present application provides a detailed description of an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication.

[0011] Step S101: parsing a communication session initialization instruction issued by an application layer, extracting parameters related to service type, delay tolerance, and reliability requirements in the communication session initialization instruction, and generating a communication task tag based on the parameters.

[0012] In this embodiment, step S101 is the starting link of the entire adaptive protocol stack reconstruction and transaction-level data control process, and plays a key role in structurally expressing the communication task and providing a clear configuration basis for subsequent processes.

[0013] Specifically, the execution of step S101 first relies on the application layer system running in the 5G communication module to actively issue a communication session initialization instruction. This instruction can be generated by a user request, triggered by the device's built-in scheduling mechanism, or issued by an edge service policy. The instruction is generally encapsulated in the form of structured data, and its content contains at least three core parameters: service type, delay tolerance, and reliability requirements. Service types may include but are not limited to high-definition video streaming, remote device control, periodic status reporting, emergency alarm data, etc.; delay tolerance is a quantitative parameter, usually given in milliseconds (ms), which is used to indicate the maximum acceptable one-way delay of the task in network transmission; reliability requirements are also quantitative or graded parameters, indicating the degree of tolerance for data integrity, number of retransmissions, or packet loss probability, such as 0.1% packet loss rate tolerance, retransmission within two times, etc.

[0014] After receiving the communication session initialization instruction, the system first performs semantic parsing and field extraction on the structured instruction content. It can identify and process it through built-in parsing functions, protocol parsers, or mapping relationships based on configuration templates to ensure that the above three core parameters can be stably obtained and their legitimacy is verified. For example, it determines whether the delay tolerance exceeds the device capability range or whether the service type is within the range supported by the current module.

[0015] After parameter extraction and verification, the system generates a "communication task tag" based on these parameters. The communication task tag is an abstract structure used to guide the dynamic reconstruction and data control behavior of the protocol stack. It can be in the form of a JSON structure, a key-value mapping table, or a custom enumeration encoding string. The tag contains at least three fields: task_type (task type), latency_bound (latency upper bound), and reliability_level (reliability level). For example: { "task_type":"video_streaming", "latency_bound": 50, "reliability_level":"medium" } In addition, to improve the adaptation efficiency of subsequent processes, the communication task label can also be expanded to include additional information such as task start timestamp, expected duration, target end identifier, etc., to support more refined protocol path construction and data scheduling strategies.

[0016] The generation of communication task labels must ensure complete content, strong consistency, transferability, and interpretability. They must be recognized and parsed by subsequent protocol mapping decision graphs, and must also support priority classification and resource scheduling strategy matching for different task labels. Therefore, the system should combine existing task classification standards with protocol configuration templates, pre-define task label formats and classification mapping tables, and ensure that communication task labels have clear identification semantics and behavioral guidance during system operation.

[0017] In summary, step S101 completes the structured transformation from high-level application semantics to network configuration control logic by parsing the communication session initialization instruction and generating a communication task tag. This is a fundamental step in this method that connects the previous and next steps and provides the necessary semantic-driven basis for the effective execution of the protocol stack's adaptive behavior and transaction-level data management strategy.

[0018] Furthermore, parsing the communication session initialization instruction issued by the application layer, extracting parameters related to service type, delay tolerance, and reliability requirements in the communication session initialization instruction, and generating a communication task label based on the parameters includes: Extracting a service type field, a delay tolerance field, and a reliability requirement field from the communication session initialization instruction, and performing a field-level comparison between the extracted fields and a service type standard table, a delay tolerance reference table, and a reliability level comparison table maintained by the current communication module to generate a communication attribute parameter set including a standardized service type, a standardized delay tolerance, and a standardized reliability level; Input the communication attribute parameter set into the label preprocessing structure, jointly analyze the standardized delay tolerance and the standardized reliability level, and construct a communication stability requirement vector. The communication stability requirement vector includes a delay threshold, a minimum confirmation period, and a maximum loss tolerance, which is used to characterize the scheduling sensitivity characteristics of the task; Based on the communication stability requirement vector and the standardized service type, searching a task template database for a preset template fragment that is consistent with the standardized service type and matches the scheduling sensitivity feature, extracting structure fields in the template fragment, including a task identification field, a scheduling level field, and a transmission path indication field, to generate an intermediate label structure; Structural fusion of the intermediate tag structure and the communication attribute parameter set, supplementing the task identification field and the scheduling level field in the intermediate tag structure so that it has the ability to uniquely identify the current communication task, and outputting the fused communication task tag draft; The draft communication task label is input into the label integrity verification module, and the final communication task label is generated according to the task uniqueness rule of the current transaction context.

[0019] The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication described in the present invention provides a complete, clear, and feasible technical path, so that the generation of communication task labels no longer relies on simple field splicing or intuitive mapping, but instead gradually refines and constructs communication task labels with uniqueness, stability, and scheduling adaptability through multiple structured processing stages.

[0020] In a specific implementation, after receiving the communication session initialization instruction from the application layer, the communication module first performs a field-level data extraction operation. The communication session initialization instruction is a structured data message, which usually contains multiple parameter segments, including at least a service type field, a delay tolerance field, and a reliability requirement field. The service type field is used to indicate the upper-layer business scenario corresponding to this session, such as video calls, remote device control, periodic data synchronization, alarm push, etc. The delay tolerance field indicates the maximum acceptable duration of one-way transmission delay for this task, generally in milliseconds; the reliability requirement field is used to describe the task's requirements for the data transmission success rate, which may be encoded in the form of levels (such as "high", "medium", "low") or values ​​(such as allowing a packet loss rate of 0.01%).

[0021] After extracting these fields, the system compares them against three standard mapping tables pre-maintained in the communication module. These three mapping tables are the service type standard table, the latency tolerance reference table, and the reliability level comparison table. The service type standard table maps all upper-layer service types to functional categories in the communication protocol stack, such as "bulk-data-transfer," "low-latency-control," and "real-time-streaming." The latency tolerance reference table classifies different latency ranges into standard levels (e.g., 0–20ms for "low latency," 20–100ms for "medium latency," and above 100ms for "high latency"). The reliability level comparison table converts numeric or textual inputs into standardized reliability levels (e.g., R1, R2, and R3). Through field-level comparison, raw fields are converted into standardized service types, standardized latency tolerances, and standardized reliability levels, thereby forming a unified communication attribute parameter set.

[0022] The communication attribute parameter set, a structured object containing three standardized fields, is then fed into the label preprocessing structure for further parsing. At this stage, the focus is on the joint relationship between the standardized delay tolerance and the standardized reliability level. Based on the combination of these two dimensions, the system constructs a communication stability requirement vector. This communication stability requirement vector is not simply a concatenation of the original fields; instead, it is derived to derive three parameters: the delay threshold (expressed in milliseconds, used to guide dynamic flow control strategies); the minimum acknowledgment period (expressed in milliseconds, used to determine the frequency of ACK packets); and the maximum loss tolerance (expressed as a percentage, used to configure the strength of the retransmission strategy).

[0023] The derivation of the delay threshold is based on the standardized delay tolerance. The delay level is converted into the corresponding maximum acceptable one-way transmission delay through a lookup table or linear mapping model. For example, the "low delay" level is mapped to a delay threshold of no more than 30ms.

[0024] The derivation of the minimum acknowledgment period is based on the constraints of a latency threshold and a standardized reliability level. The core principle is to balance the protocol overhead associated with sending acknowledgments (ACKs) with the sliding rate of the send window, while remaining within the latency threshold. Specifically, the system first determines the maximum acceptable waiting time for acknowledgments within each transmission cycle based on the derived latency threshold. For example, if the latency threshold is 30ms, the system sets the acknowledgment period to no more than 30ms. Then, considering the expected acknowledgment frequency corresponding to the reliability level (e.g., a high reliability level requires at least one ACK after every N packets sent), the system converts this acknowledgment frequency into a time period and compares it with the aforementioned latency constraint. The final minimum acknowledgment period is the smallest feasible value that simultaneously satisfies the requirements of "the number of ACK responses within each acknowledgment period is at least the required value" and "the acknowledgment period length does not exceed the latency threshold." If the system detects a value that satisfies the intersection of these two boundary conditions, it considers that value to be the minimum acknowledgment period. For example, if the transmission rate is 100 data packets per second and the high reliability level requires confirmation every 10 packets, then the lower limit of the confirmation period is 100ms; if the delay threshold is 60ms, then the final confirmation period is 60ms or shorter. The specific value is dynamically adjusted by the system according to the load to ensure a balance between feedback timeliness and communication efficiency.

[0025] The derivation of the maximum packet loss tolerance is primarily based on standardized reliability levels. A recommended upper limit for packet loss rate is mapped from a reliability level comparison table, such as "R1" corresponding to 0.01% and "R2" corresponding to 0.1%. This upper limit is further refined based on the retransmission tolerance of the mission type. All three derivation processes are based on the communication module's preset static configuration table and mission behavior characteristic curves, ensuring consistent parameter output and engineering reproducibility.

[0026] These parameters are used together to characterize the current task's tolerance for latency fluctuations, confirmation frequency, and data integrity, and constitute the quantifiable scheduling sensitivity characteristics of the task during scheduling and path construction.

[0027] The generated communication stability requirement vector is used as a keyword along with the standardized service type and entered into the task template database for query. This task template database is pre-loaded by the communication module and contains a large number of defined task template fragments, each corresponding to a typical business scenario and communication behavior pattern. The database supports dual-condition screening based on service type consistency and scheduling sensitivity feature matching to ensure that the selected template has structural correspondence and policy adaptability. The system extracts core structure fields from the matching template, including at least a task identification field (used to identify the current task type), a scheduling level field (used to indicate scheduling priority), and a transmission path indication field (used to recommend a default or preferred protocol path). These fields together constitute the intermediate label structure.

[0028] Next, the system performs a structural fusion process. The intermediate tag structure is merged with the aforementioned communication attribute parameter set, and the task identification and scheduling level fields are supplemented to ensure distinctiveness and uniqueness. This supplementation process references the existing transaction number pool, the set of running tasks, and the distributed numbering mechanism in the current module to ensure that the generated communication task tags are conflict-free within the current transaction space and do not cause task identification ambiguity. The output of this fusion is called the communication task tag draft, which is a complete tag unit that integrates the current task logic information, scheduling characteristics, and system status.

[0029] To prevent structural omissions or conflicts in the draft communication task label, the system performs a final integrity check. The label integrity check module compares the uniqueness of the task identification field, the scope validity of the scheduling level field, and the compatibility of the path indication field against the task uniqueness rules maintained in the current transaction context. Once all verification conditions are met, the system generates the final communication task label and writes it into the task identification field of the transaction control structure. This label is then used for subsequent identification and invocation of the protocol mapping decision graph, as well as for reference throughout the entire process of protocol path construction, transaction identifier allocation, and data scheduling strategies.

[0030] The entire process is completed entirely based on structured field processing, standard mapping, rule combination and consistency verification mechanism, ensuring that the generation of communication task labels is not only clear, stable and unique, but also strongly coupled with the system protocol structure. It is an indispensable technical support link in the implementation path of the present invention.

[0031] Step S102: Obtain status data of the current 5G network environment, wherein the status data includes a channel quality indicator value, average uplink and downlink delay, available bandwidth, and congestion level, and construct a network status feature vector based on the status data.

[0032] In the adaptive protocol stack reconstruction and transaction-level data control method for 5G communication described in the present invention, step S102 plays a key role in providing a real-time network perception basis for protocol path reconstruction and data scheduling. Its core goal is to accurately obtain the status data of the network environment in which the current 5G communication module is located, and based on the data, construct a network status feature vector that can be used for algorithm judgment, thereby providing support for subsequent protocol module selection, transaction scheduling priority determination, etc.

[0033] In specific implementation, the system first starts the network status perception module, which can be hosted by the communication management subsystem or scheduling control unit embedded in the 5G communication module. This module accesses hardware registers, RF feedback, MAC layer statistics, etc. through the interface in the underlying physical layer and protocol stack to obtain multi-dimensional status data in the current environment. The status data includes at least the following parameters: The first category is the Channel Quality Indicator (CQI), which is derived from UE measurements of downlink signals and is typically expressed as an integer, such as a value between 0 and 15. The CQI reflects the maximum modulation and coding level supported by the current frequency band and indirectly indicates link quality. The system obtains the latest CQI value by calling the NR physical layer interface and performs a sliding window average over multiple time intervals to eliminate short-term jitter interference.

[0034] The second category is average uplink and downlink latency. This latency value can be collected through instrumentation in the protocol stack. This involves recording the timestamp when sending a packet, calculating the round-trip time (RTT) after receiving an ACK, and then estimating the one-way latency based on pre-defined rules. The system should establish independent latency measurement paths for uplink and downlink, and support real-time updates.

[0035] The third category is available bandwidth information. This parameter can be obtained indirectly or directly. In direct acquisition, the module can access the scheduled bandwidth allocation information exposed by the network card layer or MAC scheduler. In indirect acquisition mode, the system can estimate the actual bandwidth window by combining data transmission rate, ACK response rate, and packet loss.

[0036] The fourth category is the network congestion level, which can be estimated by analyzing indicators such as buffer queue length, retransmission frequency, and ACK delay trends. The specific method is to accumulate congestion-indicating events (such as duplicate ACKs and window shrinkage) per unit time as a congestion factor. The current congestion level is then extracted based on the curve of its change within a sliding time window.

[0037] After acquiring all the aforementioned state data, the system must execute a unified feature construction process, which standardizes the multi-dimensional state parameters and combines them into a set of structured vectors, known as "network state feature vectors." In actual coding implementation, this vector can be in a key-value pair format with a fixed field order, for example: { "CQI": 12, "UL_Delay": 35, "DL_Delay": 40, "Bandwidth": 18.2, "Congestion_Level": 0.67 } In the preceding JSON-formatted network status feature vector, "CQI" represents the channel quality indicator, which reflects the current downlink quality level; "UL_Delay" represents the average uplink delay in milliseconds; "DL_Delay" represents the average downlink delay in milliseconds; "Bandwidth" represents the current available bandwidth in Mbps; and "Congestion_Level" represents the network congestion level, typically a decimal between 0 and 1, with larger values ​​indicating more severe congestion.

[0038] To ensure system adaptability and scalability, the network state feature vector should have field expansion capabilities and be adaptable to different network standards and protocol requirements. Furthermore, the vector must support joint matching with communication task labels, be transferable and parseable, and be recognized and invoked by the protocol mapping decision graph module.

[0039] During deployment, it is recommended that the network status awareness module operate under a periodic scheduling mechanism. The sampling period can be dynamically adjusted based on system load and real-time service requirements. For example, the sampling frequency can be increased to 50ms in high-density transmission scenarios and relaxed to over 200ms in static scenarios. After each round of collection, the network status feature vector should be immediately refreshed and submitted to the subsequent protocol mapping module for use.

[0040] In summary, step S102 comprehensively collects key status parameters closely related to communication performance in the 5G network environment and constructs them into a network status feature vector in a unified format, providing a solid data foundation for the system to implement protocol stack reconstruction and dynamic adjustment of transaction control strategies, which is the basic guarantee for realizing the core adaptive capabilities of the present invention.

[0041] Furthermore, the state data of the current 5G network environment is obtained, the state data including the channel quality indicator value, the average uplink and downlink delay, the available bandwidth and the congestion level, and a network state feature vector is constructed based on the state data, including: Continuously collect channel quality indicator values, uplink average delay, downlink average delay, available bandwidth, and congestion level at fixed time intervals, and add a timestamp to each set of status data as the data record for the current sampling period; Perform sliding window processing on each type of state data over multiple consecutive sampling periods, extract the average value, maximum offset, and change rate of the state data, and calculate the sampling stability factor based on this. The sampling stability factor is used to measure the degree of fluctuation of the state data within the time period; Combine each type of state data with the corresponding sampling stability factor, identify abnormal data items whose change rate exceeds a preset threshold, and assign a set of stability weights to each type of state data; Based on the stability weight and the original state data, a weighted average is performed on the channel quality indicator value, the average uplink delay, the average downlink delay, the available bandwidth, and the congestion level to obtain a weighted state data set with time consistency and noise suppression capabilities; The weighted status data set is organized into a unified structure format according to a preset field sequence, and a network status feature vector including a channel quality indicator value, an uplink average delay, a downlink average delay, available bandwidth, and a congestion level is generated.

[0042] The adaptive protocol stack reconstruction and transaction-level data control method for 5G communications described in this paper proposes a dynamic state perception method that features temporal continuity, anomaly suppression, and field-normalized organization. This method not only ensures the temporal integrity and accuracy of state data but also significantly enhances the network state feature vector's ability to resist transient fluctuations, providing a more stable and reliable input basis for protocol reconstruction decisions.

[0043] During implementation, the communication module first continuously collects network status data at fixed intervals. This sampling period can be set based on system load, task type, or scheduling priority, with typical values ​​such as 50ms, 100ms, or 200ms. During each sampling period, the communication module uses standard interfaces established by the physical and midlayer layers to collect five core parameters: channel quality indicator (CQI), average uplink latency, average downlink latency, available bandwidth, and congestion level. These parameters are typically generated in real time by the baseband chip, RF module, or protocol stack timing logic. For example, CQI is obtained through CSI or CQI feedback; average uplink and downlink latency are calculated from transport layer timestamps and ACK response intervals; available bandwidth is estimated from the total number of allocated resource blocks and the actual transmission rate; and congestion level is calculated by combining buffer backlog and retransmission rate. Each parameter type must be synchronized with the current timestamp during collection to facilitate identification of the sample's temporal sequence and sampling period during subsequent processing.

[0044] After status data collection is complete, the system does not directly use these raw values. Instead, it introduces a sliding window mechanism for multi-cycle aggregation. Specifically, at the arrival of each new sampling period, the system extracts samples of similar parameters from the most recent several periods, including that period, such as a sliding window consisting of nearly five sampling points. Within each sliding window, the system performs statistical analysis on the channel quality indicator value, average uplink delay, average downlink delay, available bandwidth, and congestion level, calculating their average value, maximum offset (i.e., the range within the window), and rate of change (defined as the average of the absolute value of the difference between the values ​​in two adjacent periods). These statistical features are used to characterize the stability of the current network status.

[0045] Based on these statistical results, the system then calculates a value called the sampling stability factor. This factor is a weighted evaluation metric constructed by combining the maximum offset and the rate of change, reflecting the intensity of fluctuations in a specific state data within the current window. For example, if the maximum offset of a certain type of state data is small and the rate of change is close to zero, the stability factor approaches 1, indicating a stable state. Conversely, if the offset is large, the stability factor approaches 0, indicating severe fluctuations. This factor serves as a reference indicator for subsequent anomaly identification and weighted calculations.

[0046] Once the stability factor is determined, the system combines it with each type of status data for analysis. If the rate of change in a particular type of status data exceeds a preset safety threshold (this threshold can be determined based on historical stability or service requirements, such as a CQI change exceeding four levels or a latency spike exceeding 50ms), the data is considered abnormal and assigned a low stability weight. Conversely, parameters that change steadily receive a high weight. For example, if the congestion level fluctuates dramatically over three cycles, its stability weight might be set to 0.2; while if the channel quality remains stable, its stability weight might be set to 0.9. This weight is used in subsequent weighted averaging.

[0047] After assigning stability weights, the system performs a weighted average on each type of state data. Specifically, each sample value within the sampling window is multiplied by the stability weight corresponding to its period. The weighted sum is then divided by the total weight value to obtain the weighted average of the state parameter. The weighted state data set generated in this way can effectively suppress abnormal deviations caused by sudden network fluctuations or missampling, demonstrating stronger timing continuity and signal authenticity, making it a useful reference for communication protocol reconstruction.

[0048] Finally, the system organizes the five weighted status data types described above into a vector representation in a fixed field order, generating a network status feature vector. This vector structure explicitly includes five fields: channel quality indicator value, uplink average delay, downlink average delay, available bandwidth, and congestion level. Their data types, units, and order are fixed during system design. For example, the channel quality indicator value is encoded as an integer (e.g., 0–15), delay is in milliseconds, bandwidth is in Mbps, and congestion level is a decimal between 0 and 1. This unified representation of structured fields allows the network status feature vector to be directly invoked by the protocol mapping decision process, participating in key operations such as protocol path selection, protocol module loading decisions, and data scheduling policy decisions.

[0049] The following provides a complete specific example to illustrate the key data processing logic.

[0050] In an actual 5G communication environment, the system continuously collects five types of status data at fixed intervals of 100 milliseconds, with a sliding window corresponding to five consecutive sampling periods. The following is an example of the raw status data collected: channel quality indicator values ​​are 10, 12, 11, 13, and 12, respectively; uplink average latency is 42ms, 45ms, 43ms, 90ms, and 44ms, respectively; downlink average latency is 38ms, 41ms, 39ms, 87ms, and 40ms, respectively; available bandwidth is 24Mbps, 23Mbps, 22Mbps, 14Mbps, and 21Mbps, respectively; and congestion levels are 0.25, 0.30, 0.28, 0.85, and 0.27, respectively. During the collection process, the system adds a timestamp to each set of status data, recording the corresponding sampling moment to ensure temporal consistency and traceability for subsequent processing.

[0051] The system then performs sliding window processing on each type of status data within the aforementioned sampling period. Taking "uplink average delay" as an example, the system calculates its average value to be 52.8ms, with a maximum offset of 90ms-52.8ms = 37.2ms. The rate of change is the mean of the consecutive differences, i.e., (|45-42| + |43-45| + |90-43| + |44-90|) / 4 = (3 + 2 + 47 + 46) / 4 = 24.5ms. The system further normalizes this rate of change to the maximum allowable variation (set to 100ms in this example), resulting in a normalized rate of change value of 0.245. Based on this, the system calculates the sampling stability factor S = 1 / (1 + 37.2 × 0.245) ≈ 0.099, which measures the intensity of fluctuations in this type of data within the sliding window. For sampling periods whose maximum offset exceeds the set abnormality judgment threshold (for example, 30ms), the system records it as an abnormal period and assigns a stability weight W based on the S value. Its value is min(1, max(0.05, S)), that is, W=0.099.

[0052] When performing weighted processing, the system sets the normal sample weight to 1 for the five data points in the sliding window, and uses the stability weight value calculated above for abnormal samples. Taking "uplink average delay" as an example, the system performs weighted average calculation as follows: Weighted average = (42×1 + 45×1 + 43×1 + 90×0.099 + 44×1) / (1 + 1 + 1+ 0.099 + 1) = 182.91 / 4.099 ≈ 44.64ms.

[0053] The system also uses the same sliding window processing, stability factor calculation and weighted averaging method for other types of status data, obtaining the following weighted status data set: channel quality indicator value is 11.5, uplink average delay is 44.64ms, downlink average delay is 39.85ms, available bandwidth is 22.1Mbps, and congestion level is 0.33.

[0054] Ultimately, the system organizes the weighted state data set into a structured network state feature vector according to a preset field order. This feature vector is encapsulated in a dictionary format and serves as input for protocol mapping and transaction-level data scheduling in subsequent steps to ensure the accuracy and adaptability of network state responses and resource allocation strategies. For example, the network state feature vector contains the following: { "CQI": 11.5, "UL_Delay": 44.64, "DL_Delay": 39.85, "Bandwidth": 22.1, "Congestion_Level": 0.33 } Through the above detailed implementation process and complete calculation examples, the implementation methods of the present invention in state data fluctuation analysis, anomaly identification, stability factor modeling and weighted denoising processing can be clearly reflected, ensuring that the constructed network state feature vector has time consistency, anti-interference ability and parameter interpretability, further improving the subsequent protocol path construction and transaction scheduling accuracy, and effectively meeting the real-time and reliability requirements in 5G communication scenarios.

[0055] Step S103: inputting the communication task label and the network state feature vector into a protocol mapping decision graph to generate a protocol reconstruction instruction, wherein the protocol reconstruction instruction is used to control the loading and unloading operations of the protocol module in the protocol stack resource pool.

[0056] In the method described in the present invention, the core objective of step S103 is to determine the protocol stack configuration that the current 5G communication module should adopt in a given context based on the communication task label and the network state feature vector, and to generate protocol reconstruction instructions accordingly to guide subsequent protocol module loading and unloading operations. This step serves as a key bridge between application layer perception and protocol stack structure adjustment. Its execution process should have clear input and output logic, a stable decision-making basis, and clear control results to ensure that the protocol stack can achieve effective adaptive reconstruction based on the combined conditions of communication tasks and network status.

[0057] When executing this step, the system first receives the communication task label and network status feature vector generated from steps S101 and S102 respectively. These two pieces of input information together constitute the behavioral intention and transmission background of the current communication environment. The service type, delay tolerance, and reliability requirements carried in the communication task label reflect the functional requirements of the protocol characteristics for this communication, while the network status feature vector describes the possible limitations of the protocol transmission performance under the current link conditions. In order to establish a computable matching relationship between the two, the system pre-constructs a protocol mapping decision map, which can be a data structure, decision table, or rule engine, containing recommended protocol stack configuration schemes under different combination conditions.

[0058] For example, in one implementation, the protocol mapping decision graph is organized as a rule table. Each rule specifies a set of communication task parameters and a protocol path combination corresponding to a network status interval. This includes information such as the required protocol modules (such as TCP, QUIC, HTTP / 3), module loading priority, and whether the transport encryption layer is enabled. When matching rules, the system compares the communication task tag field with the network status feature vector field one by one, and supports fuzzy interval matching and priority scoring mechanisms to select the protocol combination configuration that best meets the current communication needs.

[0059] After the matching is complete, the system generates a protocol reconstruction instruction. This instruction encapsulates the required protocol modules and their operation types (load or unload) in a structured format, and may be accompanied by specific parameter configurations under this combination, such as protocol buffer size, MTU limit, acknowledgment policy, etc. For example, if the task type is low-latency control and the network status shows a high CQI and low congestion, the map may recommend enabling the UDP / QUIC path, disabling the TCP module, and configuring QUIC's fast handshake and short window mechanism. The generated protocol reconstruction instruction can be in the form of an internally defined control structure or translated into an operation command adapted to the protocol stack resource pool management interface.

[0060] Protocol reconfiguration instructions must meet three conditions: first, they must be accurately recognized and executed by the protocol stack resource pool management unit; second, they must include a complete list of module operations and their execution order; and third, they must have a certain redundancy check mechanism, such as preventing duplicate loading if the current protocol module is already running. To achieve these requirements, the construction of the protocol mapping decision graph must be based on extensive communication scenario modeling and policy testing results, ensuring stability and adaptability.

[0061] To summarize, step S103 generates context-adaptive protocol reconstruction instructions by jointly inputting the communication task label and the network status feature vector into the protocol mapping decision graph, so that the protocol stack can make targeted and logical module adjustments according to dynamic conditions, significantly enhancing the protocol processing flexibility and resource utilization efficiency of the communication module in the 5G environment, and providing a technical basis for the subsequent construction of transaction paths and execution of differentiated data scheduling.

[0062] Furthermore, the step of inputting the communication task label and the network state feature vector into a protocol mapping decision graph to generate a protocol reconstruction instruction includes: Constructing a structured input pair, concatenating the standardized service type, standardized delay tolerance, and standardized reliability level in the communication task label with the channel quality indicator value, uplink average delay, downlink average delay, available bandwidth, and congestion level in the network status feature vector in field-level order to form a feature fusion sequence; Based on the feature fusion sequence, a set of candidate protocol paths that fully match the service type field and satisfy the latency constraint and have a bandwidth matching degree greater than a threshold are retrieved from a preset protocol mapping decision graph, wherein each item in the protocol path set corresponds to a set of protocol module loading sequences; Performing a resource adaptability score on each protocol module loading sequence in the candidate protocol path set, wherein the resource adaptability score is calculated and generated based on the idleness, loading overhead, and unloading delay of each protocol module in the current protocol stack resource pool; Select the protocol module loading sequence with the highest resource adaptability score as the target protocol path loading plan, and set a path adaptation flag for each protocol module involved in the target protocol path loading plan. The path adaptation flag is used to indicate whether the module is currently active and needs to be reconfigured; Based on the target protocol path loading plan and the path adaptation identifier, a protocol reconstruction instruction is generated. The protocol reconstruction instruction includes a list of modules to be loaded, a list of modules to be unloaded, and configuration parameter mapping rules, which are used to control the dynamic reconstruction operation of the protocol modules in the protocol stack resource pool.

[0063] In order to achieve the goal of inputting communication task labels and network status feature vectors into the protocol mapping decision graph and generating protocol reconstruction instructions, it is necessary to build a structured and executable process. Starting from the communication task requirements and combining them with real-time network conditions, the optimal protocol path is screened out and control instructions are formed based on this that can directly drive the dynamic reconstruction of the protocol stack.

[0064] First, the system structurally fuses the standardized service type, standardized delay tolerance, and standardized reliability level in the communication task label as core attribute parameters on the task side with the network-side attribute parameters in the network status feature vector, such as the channel quality indicator value, average uplink delay, average downlink delay, available bandwidth, and congestion level. This fusion method must follow a fixed field order, that is, the task-side fields are arranged in sequence first, and the network-side fields are arranged in sequence last, forming a complete and consistent feature fusion sequence. This sequence will serve as the input index basis for the protocol mapping graph.

[0065] Subsequently, the system uses the feature fusion sequence as the search key to extract a set of candidate protocol paths from the preset protocol mapping decision map. Each protocol path in the map is associated with a service type field, and is marked with its maximum supported delay threshold, minimum required bandwidth threshold, and recommended protocol module loading sequence. The system compares the standardized service type field in the feature fusion sequence with the service type label in the map to filter out fully matched path items. On this basis, paths that meet two key constraints are further selected: one is that the standardized delay tolerance is not less than the maximum supported delay of the path, and the other is that the current available bandwidth is not less than the minimum bandwidth requirement of the path. Both constraints must be met at the same time to enter the candidate set.

[0066] After obtaining the set of candidate protocol paths, the system evaluates the resource adaptability score of the protocol module loading sequence corresponding to each path. The resource adaptability score does not rely on model prediction, but uses a deterministic calculation method and is deduced in combination with the usage status of the current protocol stack resource pool. Specifically, the system will evaluate the loading overhead of each module to be loaded, including CPU usage, memory requirements, and context initialization time. At the same time, it will evaluate the unloading delay of each module to be unloaded, including state dump time, connection interruption risk, and cache cleanup cost. In addition, the score will be weighted according to the current idleness of the module in the protocol stack resource pool, that is, whether there are idle instances that can be directly reused. All indicators will be calculated by weighted average to obtain the comprehensive resource adaptability score of the path.

[0067] The system ranks the scores of all candidate paths and selects the highest-scoring one as the final target protocol path loading plan. To avoid redundant loading or ineffective unloading of existing modules in the protocol stack, the system sets a path adaptation flag for each protocol module in the path loading plan. This flag is determined based on factors such as whether the module is currently active, whether it is referenced by other paths, and whether there are version inconsistencies. If the module is currently loaded and the configuration is consistent, it is marked as "Keep"; if the module is not loaded or the configuration needs to be updated, it is marked as "Need to Load"; if the module is redundant or irrelevant to the path, it is marked as "Need to Unload."

[0068] Ultimately, the system generates structured protocol reconstruction instructions based on the target protocol path loading plan and path adaptation identifier. These instructions contain three types of content: first, a list of modules to be loaded, each with its module name, priority, and loading parameters; second, a list of modules to be unloaded, each with its module name, dependency disconnection status, and delayed recycle flag; and third, configuration parameter mapping rules, including inter-module context parameter transfer paths, interface binding parameters, and callback registration information. These instructions serve as the direct execution basis for subsequent protocol path construction, driving the dynamic loading and unloading of protocol modules within the protocol stack resource pool.

[0069] The performing resource adaptability scoring on each protocol module loading sequence in the candidate protocol path set includes: The resource adaptability score is calculated for each protocol module loading sequence in the candidate protocol path set according to the following formula: ; in, Indicates the comprehensive resource adaptability score of the protocol module loading sequence, in dimensionless units; Indicates the total number of protocol modules in the loading sequence; Indicates the first Primer for each protocol module; Indicates the The idleness of each protocol module, in percentage ( ), represents the proportion of unoccupied computing resources of the module in the current protocol stack resource pool; Indicates the The loading overhead of a protocol module, in milliseconds (ms), refers to the average initialization delay required to load the module into the protocol path; The preset benchmark loading delay constant is in milliseconds (ms); Indicates the The unloading delay of a protocol module, in milliseconds (ms), reflects the average resource release time required to remove the module from the current protocol path; Indicates the The functional weight of each protocol module in the protocol path is dimensionless and is determined by the importance of the protocol layer in the communication task. is the unloading attenuation factor, in units of , used to adjust the negative correlation weight of the uninstall delay on the score value. The recommended value range is .

[0070] Step S104: According to the protocol reconstruction instruction, at least one protocol module is loaded or unloaded from the protocol stack resource pool to construct a protocol path that meets the requirements of the communication task label and the network state feature vector, and a transaction identifier is assigned to each protocol path.

[0071] In the method of the present invention, step S104 is the core operation link for formally executing the protocol stack structure adjustment after completing communication task analysis and network status perception, and generating protocol reconstruction instructions based on this. Its goal is to enable the protocol stack to achieve functional tailoring and reconstruction based on the current communication scenario, thereby constructing a more adaptable protocol path and assigning a manageable transaction identifier to each path to facilitate transaction-level control of subsequent data scheduling. The execution of this step should ensure that the loading and unloading of protocol modules is controllable, atomic, and traceable, and can provide complete support for the identification, registration, and maintenance of transaction paths during the construction process.

[0072] When entering this step, the system receives the protocol reconstruction instruction output from step S103, which clearly lists the protocol module items to be loaded and unloaded. Protocol modules are generally standard protocol components pre-deployed in the protocol stack resource pool, which may include but are not limited to IP, TCP, UDP, QUIC, TLS, HTTP / 2 or HTTP / 3. Each module in the resource pool should exist in an addressable and callable form and have a module lifecycle management mechanism, such as supporting status query, loading initialization, parameter configuration and resource release. Loading and unloading operations are usually initiated through the protocol stack manager interface. The system calls the relevant control interfaces in the resource pool in sequence according to the protocol reconstruction instruction to complete the mounting or removal of the protocol module.

[0073] Before loading a protocol module, the system first checks whether the module is already active. If so, it avoids re-loading. If not, it calls its initialization function to set basic parameters, such as cache size, retransmission strategy, and handshake configuration. For unloading operations, the system needs to determine whether the module is in an active link. If a data transmission context exists, a buffer flush or redirection operation is required before unloading to avoid abnormal protocol path breakage. After the module is loaded, the system will connect the modules into a protocol path in the order specified in the reconstruction instruction, such as "IP → UDP → QUIC" or "IP → TCP → HTTP / 3", to form a complete data transmission and reception channel.

[0074] After the protocol path is constructed, the system generates a transaction identifier for the path. This identifier uniquely identifies the path and is used to subsequently associate data transmission behavior, state caching, and scheduling information. Transaction identifiers can be encoded in 16-bit or 32-bit formats, ensuring uniqueness, traceability, and lifecycle control. The system maintains an internal transaction identifier registry, binding each assigned transaction identifier with metadata such as the corresponding protocol path structure, service type tag, expected task duration, and priority level. This facilitates differentiated processing of different transactions during subsequent data scheduling.

[0075] To ensure system scalability and high concurrency, transaction identifiers should be allocated using a thread-safe mechanism, such as using a mutex or lock-free queue to control the identifier pool. Transaction identifiers should be promptly released after communication is complete and returned to the identifier pool for reuse by subsequent tasks. Furthermore, the system can set a timeout policy for each transaction identifier, automatically clearing and releasing resources after extended periods of inactivity to prevent state accumulation.

[0076] An operation rollback mechanism can also be set during the execution of the entire step. That is, if there are abnormal situations such as module initialization failure, path construction conflict, insufficient resources, etc. during the process of loading the protocol module or establishing the path, the system should actively terminate the operation, release the allocated resources, and return to the protocol reconstruction decision module to re-evaluate the configuration plan to ensure the integrity and fault tolerance of the protocol path configuration.

[0077] In summary, step S104 not only implements on-demand loading and unloading of the protocol stack, but also establishes a path-oriented data control infrastructure through the introduction of transaction identifiers, providing a highly controllable and traceable execution object for the subsequent data scheduling, priority management, and flow control strategies of the present invention, and is the key hub for realizing the adaptive communication capabilities of the entire system.

[0078] Furthermore, the method of loading or unloading at least one protocol module from the protocol stack resource pool according to the protocol reconstruction instruction to construct a protocol path that meets the requirements of the communication task label and the network state feature vector, and assigning a transaction identifier to each protocol path, includes: Performing a field-level difference comparison between the list of modules to be loaded in the protocol reconstruction instruction and the set of modules already loaded in the current protocol stack to generate a module loading plan difference set for indicating the protocol modules that need to be newly loaded; For each protocol module in the module loading plan difference set, according to its required dependent module list and context initialization parameter rules, all directly dependent and indirectly dependent modules are retrieved and marked from the protocol stack resource pool to build a recursive loading dependency chain; Module loading is performed according to the calling order between modules in the recursive loading dependency chain. During the loading operation, module context parameters are initialized and interconnected according to the configuration parameter mapping rules defined in the protocol reconstruction instructions. After all target protocol modules are loaded, a protocol path fingerprint is generated based on the current communication task label and the network status feature vector. The protocol path fingerprint is then compared with the historical path fingerprint library in the resource pool to determine whether a similar path structure exists. If no match is found, a unique transaction identifier is created and the path structure is registered in the path index table. The transaction identifier is bound to the currently constructed protocol path, and a protocol path status descriptor is generated. The protocol path status descriptor includes the operating status, context activity status and most recently used timestamp of each module in the path, which is used as a reference for subsequent data scheduling and resource recovery.

[0079] This embodiment aims to implement a dynamically adjustable protocol stack structure reconstruction mechanism to flexibly adapt to the differentiated performance requirements of different communication services in the 5G network environment. This process starts with the protocol reconstruction instruction as input and completes a series of operations such as protocol module difference identification, dependency resolution, sequential loading, path generation, and transaction identifier binding according to structured logic, ensuring that the protocol path meets the requirements of the target communication task in terms of functional integrity, resource accessibility, and execution consistency.

[0080] First, upon receiving the protocol reconstruction instruction, the system extracts a list of modules to be loaded and performs a field-level diff comparison with the set of active protocol modules in the current protocol stack. This comparison not only includes matching module names but also fields such as module version numbers and configuration parameter dependencies. This allows the system to identify protocol modules that are not currently loaded and need to be added to the protocol path, ultimately forming a module loading plan diff set. This diff set only contains the modules required for incremental loading in this round of reconstruction, thereby reducing redundant operations and improving protocol reconstruction efficiency.

[0081] Next, the system analyzes the direct and indirect dependent modules required for the operation of each protocol module to be loaded in the module loading plan difference set. Each protocol module usually maintains a dependency table in the resource pool, which lists which lower-level or horizontal modules it needs to rely on at startup, and how its context parameters are passed or generated by the dependent modules. Based on this dependency table, the system uses a depth-first traversal method to construct the complete dependency path of the module, forming a recursive loading dependency chain. In this process, all dependent modules are also marked as needing to be loaded to avoid module isolation or context breakage.

[0082] After completing the dependency chain construction, the system begins to execute the protocol module loading operation according to the calling priority order between modules in the dependency chain. The loading operation is executed step by step in the order of module calls to ensure that the underlying interface or context resources required by the upper-level module are ready. When loading each protocol module, the system will initialize the context parameters of the module according to the configuration parameter mapping rules attached to the protocol reconstruction instruction. These parameters may include communication window size, receive buffer limit, handshake mechanism enable bit, etc. The mapping rules convert the communication task label and the field content in the network status feature vector into specific parameter values ​​to complete the customized configuration during the module initialization process. In addition, the system also completes the interconnection binding operation between modules, such as establishing a handle connection relationship between the TCP layer and the IP layer to ensure a smooth data path.

[0083] After the target protocol module and all its dependent modules are loaded, the system extracts the structural features of the current protocol path and generates a unique protocol path fingerprint based on the communication task label and the network status feature vector. This fingerprint is implemented by combining the module ID, loading order, configuration parameter hash value, etc., and is used to search the path fingerprint library for highly similar registered path structures. If the fingerprint match fails, the system automatically generates a new transaction identifier and registers the current protocol path structure along with its fingerprint, adaptation parameters, and other meta-information in the path index table. This index table is used in subsequent scenarios such as path reuse, conflict judgment, and rollback recovery.

[0084] Finally, the system binds the generated transaction identifier to the current protocol path and creates a protocol path status descriptor. This descriptor records the operational status of each protocol module in the path (e.g., idle, processing, or exception), context activity status (e.g., whether initialization is complete, forwarding capability is available), and the timestamp of the most recent use. This information serves as a key parameter for transaction-level data scheduling and also informs the protocol stack resource pool's reclamation strategy, such as prioritizing the cleanup of protocol paths that have been unused for a long time, are in an abnormal state, or have low activity.

[0085] Through the above process, the system not only implements the minimum incremental logic of on-demand loading of protocol modules, but also builds a path identification and state management mechanism based on transaction identifiers, significantly improving the adaptability of the protocol stack structure to the complex and changeable 5G communication environment, with high feasibility and clear technical contributions.

[0086] Step S105: establishing a transaction-level data buffer based on the transaction identifier, dividing the data to be transmitted into multiple data packets and writing them into the transaction-level data buffer, and marking each data packet with a priority tag corresponding to the communication task tag.

[0087] In the method of the present invention, step S105 plays a key role in connecting the preceding and following steps. Its task is to establish a corresponding transaction-level data buffer for the transaction path after the protocol path has been constructed based on the communication task label and the network status feature vector and uniquely identified by the transaction identifier, and to structure the data to be transmitted, divide it into multiple data packets, and attach a clear priority label to each data packet.

[0088] In actual execution, the system first allocates an independent data buffer space for each registered transaction identifier, called a transaction-level data buffer. This buffer can be implemented using a queue, a doubly linked list, or a memory block mapping. Logically, it is an independent transmission channel bound to the transaction identifier and physically resides in system memory, a DMA buffer, or a high-speed buffer. This buffer has the ability to dynamically expand and contract, and supports basic operations such as enqueueing, dequeuing, priority reordering, and rollback and refilling, providing structural support for complex data scheduling.

[0089] Before data is written to the buffer, preliminary data segmentation is required. Specifically, the system receives the data stream to be transmitted from the application layer or middleware layer, and segments the original data according to the maximum transmission unit (MTU) limit of the current protocol path. For example, when the lowest layer module in the protocol path is QUIC, the frame length limit specified by QUIC can be used for packet segmentation. Each data packet should include basic structures such as the data payload area, data identification field (such as sequence number), check field, and scheduling flag bit to ensure that it can be correctly parsed and forwarded in the protocol stack.

[0090] Before a data packet is written to the transaction-level data buffer, the system needs to attach a priority tag to each data packet. The priority tag is derived from the three elements of service type, delay tolerance, and reliability requirements contained in the aforementioned communication task tag, and can be further refined in combination with the semantic tagging of the data content. For example, if the communication task label is "low latency + high reliability", the system can divide the data packet into three categories: "critical data", "important data", and "non-critical data", and assign "P1", "P2", and "P3" level labels respectively. The priority tag can be embedded in the data packet header structure, or by establishing a mapping relationship with the index table in the buffer structure, the system can quickly identify the priority information of each data packet during reading, scheduling, and retransmission.

[0091] The priority tag generation mechanism should be flexible and extensible, with explicit interpretation logic, such as the basis for setting priority levels, allocation strategies, and factors linked to network status. In actual deployment, priority tags can be set as fixed-length enumeration fields (such as 2 or 3 bits) or employ more complex weighting values ​​(such as 0 to 100) to facilitate weighted scheduling by subsequent flow control algorithms. Furthermore, the system can incorporate dynamic information such as packet generation timestamps, queue retention time, and retransmission history to update the effectiveness of priority tags in real time, enhancing their adaptability to the current communication environment.

[0092] After data is written, the transaction-level data buffer enters a pending state. Subsequent steps will access the data in this buffer and execute the corresponding transmission strategy based on priority. To ensure the consistency and integrity of the buffer data, the system should implement a read-write lock mechanism for the transaction-level data buffer to prevent concurrency conflicts. It is also recommended to establish a status monitoring interface for each buffer to periodically check indicators such as data volume, retention time, and packet loss history, so that the scheduling module can make dynamic adjustments.

[0093] To sum up, step S105 segments the data to be transmitted by establishing a transaction-level data buffer bound to the transaction identifier, and attaches a priority tag reflecting the characteristics of the communication task to each data packet, so that the data is controllable and identifiable before being scheduled, providing strong support for the subsequent execution of differentiated flow control based on priority and network status, and is an important basic link for realizing the core functions of the present invention.

[0094] Furthermore, the step of establishing a transaction-level data buffer based on the transaction identifier, dividing the data to be transmitted into a plurality of data packets and writing the data packets into the transaction-level data buffer, and marking each data packet with a priority tag corresponding to the communication task tag includes: After binding the transaction identifier to the currently constructed protocol path, generating a structured data partitioning parameter set based on the maximum bearer unit length and supported fragment structure of each protocol module in the protocol path, and using the structured data partitioning parameter set as a basis for data partitioning configuration; performing length-controlled segmentation on the data to be transmitted based on the structured data segmentation parameter set, and appending the transaction identifier, sequence number, and checksum tag to each segmented segment to form a set of data packets to be buffered, wherein the set of data packets to be buffered serves as a target object for writing into the transaction-level data buffer; Extracting the standardized service type, standardized delay tolerance, and standardized reliability level from the communication task tag, generating a unique priority tag for each data packet in the set of data packets to be buffered according to a priority coding rule table bound to the three extracted fields, and embedding the priority tag into a control field of the data packet; Based on the priority tag and current free space information of the transaction-level data buffer, a cache slot dynamic allocation operation is performed to determine the storage location of each data packet to be buffered in the transaction-level data buffer, and a buffer scheduling index table is generated to indicate the processing order between packets; According to the buffer scheduling index table, a transaction-level data buffer queue structure is established with the priority tag as a scheduling keyword, and the transaction-level data buffer queue structure is used as a transaction-level data buffer area.

[0095] During implementation, the previously constructed protocol path must first be bound to the transaction identifier. This binding ensures that each protocol path has an independent and traceable data processing link during subsequent data transmission. Specifically, the system stores the currently loaded protocol path structure information in the transaction path mapping table based on the transaction identifier, and uses the path's unique identifier to confirm subsequent scheduling and cache ownership.

[0096] After the binding is completed, it is necessary to extract parameters field by field and generate a structured data partitioning parameter set based on the maximum bearer unit length supported by all protocol modules involved in the protocol path (for example, the maximum number of bytes per frame) and whether data fragmentation transmission is supported. This parameter set will clearly define the minimum packet length and maximum packet length that should be followed when dividing data packets, whether the first and last packets are allowed to be of unequal length, and the ability of each protocol module to support the fragment index field in the path. For example, if the transmission control protocol module in the protocol path limits the maximum data segment to 1024 bytes, and the frame structure supported by the underlying bearer protocol is 1200 bytes, the system needs to construct a partitioning rule with a partitioning unit of no more than 1024 bytes. This structured data partitioning parameter set will serve as the configuration basis for subsequent data packet partitioning.

[0097] Based on the above configuration parameters, the system receives data to be transmitted from the upper-layer application and initiates the data segmentation process. During the segmentation process, the system truncates the input data to a size that is closest to, but does not exceed, the maximum load unit length. A complete transaction identifier is attached to each segmented data fragment to ensure clear fragment ownership. Furthermore, to ensure reliable sequence recovery and verification, each data packet is appended with a sequence number field and a checksum tag generated using a CRC or other hash algorithm, forming a set of data packets to be buffered. This set of data packets to be buffered constitutes the target data object for subsequent writes to the transaction-level data buffer.

[0098] Next, the system extracts three key fields from the communication task tag: standardized service type, standardized delay tolerance, and standardized reliability level. Based on a built-in priority encoding rule table, it generates a unique priority tag for each packet. The priority encoding rule table is a multidimensional mapping structure that calculates a corresponding priority value based on different combinations of service type (such as video, voice, and control signaling), delay tolerance (e.g., 5ms, 50ms, 200ms), and reliability level (e.g., 99%, 99.99%, 99.999%). Lower values ​​represent higher priority. The generated priority tag is embedded in the control field of the packet, ensuring that it can be identified and processed according to priority during subsequent scheduling and transmission.

[0099] The system then dynamically allocates cache slots based on the free space in the current transaction-level data buffer. This operation first scans the size and distribution of the available slots within the current buffer and, based on the size requirements of each packet, selects the most appropriate slot for write location allocation. The allocation results are recorded in the buffer scheduling index table, which uses the transaction identifier, sequence number, and priority tag as core fields to indicate the physical storage address and recommended processing order for each packet in the buffer.

[0100] Finally, based on the aforementioned buffer scheduling index table, the system constructs a transaction-level data buffer queue structure with priority tags as scheduling keywords. This buffer queue is organized using ascending priority or customized scheduling strategies (such as weighted round-robin or shortest delay first) to ensure that high-priority packets are processed and sent first when network conditions are tight or buffer resources are limited. The transaction-level data buffer queue structure will be formally labeled as a transaction-level data buffer. In this structure, each packet has a clear transaction affiliation identifier, complete control field information, and a clear processing order index, ensuring that subsequent dynamic flow control operations performed based on the network status feature vector can be efficiently and accurately scheduled.

[0101] In summary, the above steps provide a complete data preparation and caching solution that strictly connects transaction identifiers and protocol paths, integrates communication task labels and network status feature vectors, dynamically performs data partitioning and priority control, and realizes refined scheduling through a buffer queue structure. It has strong real-time adaptability and service quality assurance capabilities, is superior to existing static protocol stack data caching and scheduling strategies, and provides reliable support for high-density heterogeneous service data transmission in 5G communication environments.

[0102] Step S106: performing dynamic flow control operations according to the network status feature vector and the priority label.

[0103] In the 5G communication control method described in this invention, the core objective of step S106 is to perform dynamic flow control on packets in the transaction-level data buffer based on the network state feature vector and priority tag, thereby achieving stable, efficient, and priority-aware data transmission control in complex and volatile wireless network environments. This step directly affects the scheduling order, transmission cadence, and retransmission mechanism of packets, and is a key component in ensuring the on-demand delivery of critical tasks and improving the overall communication performance of the system.

[0104] When performing this step, the system first needs to read and parse the current network status feature vector in real time. This vector contains parameters such as channel quality indicator (CQI), average uplink and downlink delay, available bandwidth, congestion level, etc., which represent the current network carrying capacity and link health of the system. Based on these parameters, the system will calculate one or more transmission control factors, such as the available sending window size, the expected transmission rate, or the packet loss warning threshold. At the same time, the system will also extract the priority label of each data packet to be sent. This label is pre-set during the transaction-level data buffer write phase and reflects the relative importance and timeliness requirements of the data packet in the current communication task.

[0105] After receiving these two types of input, the system will combine them to schedule the transmission order and strategy of data packets. This is done in three aspects: adjusting the sending window, rescheduling the scheduling order, and determining the retransmission strategy.

[0106] The send window is adjusted based on the bandwidth and congestion indicators in the current network status feature vector. If the system detects high congestion or a decrease in available bandwidth, it automatically tightens the send window, reducing the amount of data that can be sent per unit time to prevent further network overload. Conversely, when the link status is good and congestion is low, the send window is appropriately expanded to improve overall throughput efficiency. Based on the window changes, the system also dynamically determines which packets are eligible for the next send cycle.

[0107] Rescheduling the scheduling order is a core operation performed based on priority tags. The system extracts all pending packets from the transaction-level data buffer and reorders them based on their priority tags. For example, critical control packets at the "P1" level are sent first, less important data at the "P2" level may wait a transmission cycle before being enqueued, and low-priority data at the "P3" level or below may even be temporarily shelved when network conditions are poor. This scheduling process can be achieved by setting up weighted priority queues, ensuring that packets of different priorities are protected in a hierarchical manner when resources are limited.

[0108] The retransmission strategy determines whether to retransmit, the number of retransmissions, and the timing of retransmissions based on the priority tag after identifying a packet loss event or confirmation failure. The system will initiate the retransmission process when the ACK confirmation times out or there are signs of packet loss on the receiving end. However, not all packets are considered to be objects that must be retransmitted. The system prioritizes the integrity of critical "P1" level packets, allowing them to be retransmitted quickly or multiple times. Low-priority packets may be limited to one compensatory retransmission or directly discarded to free up resources and optimize overall transmission latency.

[0109] Furthermore, the system continuously monitors changes in network status throughout the entire process. If the network status characteristic vector experiences significant fluctuations, such as a sudden drop in bandwidth or a sharp increase in latency, it triggers an emergency flow control mechanism, suspending the transmission of non-critical data and implementing prioritized forwarding or path reconstruction instructions for critical paths. The system also supports predefined threshold policies, automatically adjusting scheduling priorities or switching protocol paths when certain status parameters exceed a safe range.

[0110] The entire dynamic flow control process must be completed within milliseconds. It is recommended that it be deployed above the transport or link layer of the protocol stack, executed by a dedicated flow control scheduler module, in conjunction with a buffer monitor and link feedback mechanism to form a closed loop. The flow control strategy can also be dynamically adjusted through configuration parameters or online learning mechanisms to adapt to different 5G communication business models and scenarios.

[0111] To summarize, step S106 uses the network status feature vector and the data packet priority label as input, executes real-time sending window control, scheduling order rearrangement, and differentiated retransmission strategy, and realizes refined flow control processing of transaction-level data in complex network environments. It is an important technical support for ensuring that the present invention maintains high reliability and low-latency communication effects under critical business and dynamic link conditions.

[0112] Furthermore, performing a dynamic flow control operation according to the network state feature vector and the priority label includes: Calculating a target transmission rate cap based on the available bandwidth field and the congestion level field in the network state feature vector, where the target transmission rate cap is used to limit the data output rate of the current transaction-level data buffer, specifically comprising: constructing a transmission suppression factor based on the available bandwidth field and the congestion level field, and applying the transmission suppression factor to a basic rate configuration of the transaction-level data buffer to generate a rate control parameter set; Combining the priority tag of each data packet to be transmitted in the transaction-level data buffer with the rate control parameter set, performing data packet rate scheduling calculation, and generating a scheduling weight sequence, wherein the scheduling weight sequence is used to describe the importance ranking of each data packet relative to the transaction priority tag under the current target transmission rate upper limit constraint; Constructing a scheduling priority queue according to the scheduling weight sequence, wherein the scheduling priority queue arranges data packets from high to low according to the scheduling weight value and serves as a candidate transmission sequence for the current scheduling period; Based on the uplink average delay field and the downlink average delay field in the network state feature vector, combined with the current free capacity of the transaction-level data buffer, the window capacity upper limit of the current scheduling period is dynamically determined, and the window capacity upper limit is used to intercept the first several data packets within the window size range from the scheduling priority queue to form a flow control packet output plan; Each data packet in the flow control packet output plan is encapsulated into a transmission queue, and a transaction identifier and a path adaptation identifier are attached during the encapsulation process. The path adaptation identifier is derived from the context activity state of the corresponding protocol module in the protocol path, and is used to perform path-level confirmation and sequence reconstruction operations at the receiving end, and the transmission queue is submitted to the link interface for output scheduling.

[0113] In the adaptive protocol stack reconstruction and transaction-level data control method for 5G communications, dynamic flow control is a crucial component in ensuring data transmission efficiency and real-time performance after the protocol path is established. After generating a transaction-level data buffer and embedding packet priority tags, this step intelligently adjusts packet scheduling output through a fine-grained flow control mechanism. This entire process, based on network state feature vectors and transaction data structures, gradually forms a complete flow control scheduling path that dynamically adapts to network changes, ensuring that communication tasks maintain quality of service (QoS) and transmission continuity even under bandwidth constraints or network fluctuations.

[0114] First of all, it is necessary to clarify the specific field composition in the network status feature vector. In the present invention, the feature vector contains multiple dimensional parameters, among which the core fields related to flow control include "available bandwidth field" and "congestion level field". The available bandwidth field represents the effective bandwidth value that can be allocated in the upstream and downstream channels of the current connection, in Mbps, and is obtained by the frequency band scheduling feedback provided in real time by the base station equipment. The congestion level field indicates the measured degree of network congestion in the communication path, which can be comprehensively quantified by indicators such as retransmission rate and RTT jitter range, and is usually represented by a standardized value between 0 and 1.

[0115] Based on these two fields, the system constructs a transmission suppression factor for traffic control. This factor can be expressed as a dynamic function, the output of which is used to adjust the original transmission rate. For example, if available bandwidth is low and congestion levels are high, the output of this factor is close to 0.3, meaning that the current allowed data output rate can only reach 30% of the default base rate. Applying this transmission suppression factor to the pre-set base rate configuration of the transaction-level data buffer (such as the initial default value of 10 Mbps) can obtain the target transmission rate upper limit, which is encapsulated as a set of rate control parameters and used as the basis for subsequent scheduling constraints.

[0116] In this invention, the transmission suppression factor is a rate adjustment weight coefficient calculated based on the "available bandwidth field" and "congestion level field" in the network status feature vector. It indicates the degree of rate suppression that should be applied to the current transaction-level data buffer, based on the original base rate configuration. This factor not only considers the current network resource availability but also incorporates congestion trends, providing dynamic adaptability.

[0117] The calculation method is as follows: First, set the "Available Bandwidth Field" to , in Mbps, represents the current channel-level available bandwidth measured by the network device or base station; set the "congestion level field" to , is a standardized value ranging from 0 to 1, where 0 indicates no congestion and 1 indicates complete congestion. This value can be derived from dynamic indicators such as the average retransmission rate and buffer queue delay jitter.

[0118] Then, introduce the upper reference limit: is the maximum supported bandwidth of the current link (which can be obtained through negotiation of network service quality parameters. The calculation formula for constructing the transmission suppression factor α is as follows: ; Indicates the current bandwidth utilization ratio of the network, which is a direct reflection of resource availability; (1 – ) indicates the degree of network smoothness. The closer it is to 1, the less congested it is. The multiplication of the two gives It varies between [0,1], and the smaller the value, the more the system should reduce the rate.

[0119] The factor The default base rate configuration applied to the transaction-level data buffer , generating the target transmission rate upper limit , calculated as: ; After obtaining the rate control parameter set, the system enters the data packet rate scheduling calculation phase. In the transaction-level data buffer, each data packet to be transmitted is accompanied by a priority tag. This tag is obtained by mapping the standardized service type, standardized delay tolerance, and standardized reliability level triples parsed from the communication task tag to indicate the task urgency of the data packet. The system associates and matches this priority tag with the rate control parameter set and executes the scheduling weight allocation algorithm. Specifically, a priority mapping table and a weighted proportional factor can be used to form a scheduling weight sequence. Each element in the scheduling weight sequence is bound to the corresponding data packet, indicating its transmission urgency and priority level ranking under rate-limited conditions.

[0120] Based on the generated scheduling weight sequence, the system constructs a scheduling priority queue, sorting packets in the queue from high to low according to their scheduling weight values. This queue is not output immediately, but serves as a candidate transmission sequence within the current scheduling cycle. It still needs to be screened by the window capacity limit mechanism before forming a final output plan.

[0121] To further adapt to the network's latency characteristics and cache load capacity, the system also combines the "uplink average delay field" and "downlink average delay field" information in the network state feature vector with the current free capacity of the transaction-level data buffer to comprehensively determine the total amount of data that can be safely scheduled during this scheduling cycle, namely the upper limit of the window capacity. The delay field reflects the current link response time. If the delay increases, the window capacity should be reduced to reduce the probability of packet loss. The free capacity provides feedback on the local buffer's carrying capacity. These two factors work together in the window estimation function to determine the current number of schedulable data packets. For example, if the system initially estimates that 10 data packets can be scheduled, the first 10 packets are selected from the scheduling priority queue in order of weight value to form the flow control packet output plan for this cycle.

[0122] After forming the flow control packet output plan, the system encapsulates each data packet one by one. During the encapsulation process, two important fields need to be added to each data packet: one is the transaction identifier, which is used to mark the transaction-level data buffer and protocol path to which the data packet belongs; the other is the path adaptation identifier, which is derived from the current context activity status of each protocol module in the protocol path. It is an important parameter that represents the real-time adaptability of the path. Its value can be calculated by comprehensively calculating the module activity counter, fault flag, status expiration time, etc. The embedding of this identifier can support the path-level confirmation mechanism and sequence reconstruction logic at the receiving end. Even if the path changes temporarily, the receiver can still perform soft switching or multi-path aggregation and reorganization based on this identifier to ensure communication continuity and sequence consistency.

[0123] Finally, the encapsulated data packets are sequentially written into the transmission queue and submitted to the link interface module for scheduling and transmission. This process is handled by the interface control module at the bottom layer of the protocol stack. Its transmission rhythm is regulated by the target transmission rate upper limit parameter. This ensures that even in high-load or sudden interference scenarios, it can maintain precise data output control, avoiding congestion spread and buffer overflow, thus realizing a highly adaptable and service-aware dynamic flow control mechanism for 5G communications.

[0124] This step in the present invention combines network status characteristics with task priorities to establish a closed-loop dynamic scheduling mechanism, covering five consecutive sub-steps: rate limiting, priority calculation, scheduling sequence formation, window current limiting and path-level encapsulation. It avoids the problem of static flow control strategies in the existing technology failing to adapt to highly dynamic 5G networks, and significantly improves communication reliability, data throughput efficiency and resource utilization balance.

[0125] Furthermore, the adaptive protocol stack reconstruction and transaction-level data control method for 5G communication further includes: After the communication process corresponding to the transaction identifier is completed, the transaction identifier and its corresponding transaction-level data buffer resources are released, and the protocol module status involved in the protocol path is written back to the protocol stack resource pool to update the current usage status of the protocol module.

[0126] This embodiment further introduces a mechanism for reclaiming communication resources and updating protocol module status. This aims to improve the dynamic scheduling efficiency of the protocol stack resource pool, avoid redundant module resource usage, and ensure the system's self-cleaning capabilities during long-term operation. This step primarily involves three specific operations: releasing transaction identifiers, releasing transaction-level data buffers, and writing back protocol module status. Each operation must clearly define boundary conditions, triggering mechanisms, and execution methods to ensure feasibility and stability in actual system operation.

[0127] When a communication task completes all data transmission, confirmation, and response processes under the corresponding transaction identifier, the system first determines whether the communication path associated with the transaction identifier still has remaining data to be processed. If the path generates no valid data activity within the set maximum idle time window, or receives a communication completion notification from the application layer or scheduling module, the communication process corresponding to the transaction is considered complete. Based on this, the system initiates the resource release process.

[0128] First, the transaction identifier itself needs to be released. In the transaction identifier allocation mechanism, each transaction identifier is a unique number within the system, typically assigned during protocol path construction and bound to multiple internal resource structures. The process of releasing a transaction identifier should include deregistering the number from the transaction identifier index table, clearing its bound path information, priority information, and transmission status records, and returning the number to the identifier pool for reuse by subsequent new transactions. In a multi-threaded or concurrent processing environment, locking or atomic operations should be used to ensure that the release operation does not conflict with resource access by other modules.

[0129] The system then releases resources in the transaction-level data buffer corresponding to the transaction identifier. This buffer, established in step S105, is used to store all pending or unacknowledged data packets in the transaction. This release operation includes clearing the corresponding buffer area in memory, resetting pointer references, and removing the buffer instance from the memory management table. If the buffer utilizes a memory pool mechanism, the occupied memory blocks must also be returned to the memory pool for reuse.

[0130] After the release operation is complete, the system needs to further process the protocol module status information associated with the transaction. Because the transaction path is dynamically constructed from the protocol stack resource pool under the influence of protocol reconstruction instructions, each loaded protocol module has status information such as running status, call count, and active flag. To ensure the consistency of the protocol stack resource pool, the system needs to write back the current usage status of these modules to the module management structure in the protocol stack resource pool. Specifically, the system iterates through all protocol modules involved in the transaction path (such as TCP, QUIC, HTTP / 3, etc.), one by one, and determines whether they are still referenced by other transactions. If the reference count of a module reaches zero, the system can mark it as "idle"; if it is still occupied by transactions, the system updates its current active transaction number list. The status writeback results are used for module selection and resource conflict avoidance during the subsequent protocol path construction process.

[0131] To avoid the system burden caused by frequent loading and unloading of protocol modules, the system can introduce a minimum residence time strategy or module hot caching mechanism, keeping newly released modules in a short standby state. If they are called again within a short period of time, they can skip the initialization process and directly activate. This can not only avoid the system overhead caused by frequent initialization, but also improve response speed in task-intensive scenarios.

[0132] The entire resource release and status write-back process should be automatically triggered at the end of the communication task lifecycle and support an error rollback mechanism to ensure that if an exception occurs during the release process (such as uncleared paths, buffer access exceptions, etc.), the system can roll back the status or mark the exception to prevent resource status confusion.

[0133] In summary, this step effectively improves the reuse efficiency of the protocol module and the system resource scheduling capability by promptly releasing the transaction identifier, clearing the data buffer resources, and writing the protocol module usage status back to the protocol stack resource pool after the transaction communication is completed. It is an essential component to support the long-term operation and continuous scheduling of multiple tasks of the method of the present invention, ensuring that the system has good resource closed-loop management capabilities and operational stability.

[0134] A second embodiment of the application provides an electronic device, comprising: processor; The memory is used to store a program, which, when read and executed by the processor, executes an adaptive protocol stack reconstruction and transaction-level data control method for 5G communication provided in the first embodiment of the present application.

[0135] The third embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the method for adaptive protocol stack reconstruction and transaction-level data control for 5G communication provided in the first embodiment of the present application is executed.

[0136] Although the present application is disclosed as above with the preferred embodiments, it is not intended to limit the present application. Any person skilled in the art may make possible changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims of the present application.

Claims

1. A method for adaptive protocol stack reconstruction and transaction-level data control for 5G communication, characterized in that: include: Parsing the communication session initialization instruction issued by the application layer, extracting parameters related to service type, delay tolerance, and reliability requirements in the communication session initialization instruction, and generating a communication task label based on the parameters; Obtaining status data of the current 5G network environment, the status data including channel quality indicator value, uplink and downlink average delay, available bandwidth and congestion level, and constructing a network status feature vector based on the status data; Inputting the communication task label and the network state feature vector into a protocol mapping decision graph to generate a protocol reconstruction instruction, wherein the protocol reconstruction instruction is used to control the loading and unloading operations of the protocol module in the protocol stack resource pool; According to the protocol reconstruction instruction, at least one protocol module is loaded or unloaded from the protocol stack resource pool to construct a protocol path that meets the requirements of the communication task label and the network state feature vector, and a transaction identifier is assigned to each protocol path; Establishing a transaction-level data buffer based on the transaction identifier, dividing the data to be transmitted into a plurality of data packets and writing the data packets into the transaction-level data buffer, and marking each data packet with a priority tag corresponding to the communication task tag; Dynamic flow control operations are performed according to the network state feature vector and the priority label.

2. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: Also includes: After the communication process corresponding to the transaction identifier is completed, the transaction identifier and its corresponding transaction-level data buffer resources are released, and the protocol module status involved in the protocol path is written back to the protocol stack resource pool to update the current usage status of the protocol module.

3. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: The parsing of the communication session initialization instruction issued by the application layer, extracting parameters related to the service type, delay tolerance, and reliability requirement in the communication session initialization instruction, and generating a communication task label based on the parameters includes: Extracting a service type field, a delay tolerance field, and a reliability requirement field from the communication session initialization instruction, and performing a field-level comparison between the extracted fields and a service type standard table, a delay tolerance reference table, and a reliability level comparison table maintained by the current communication module to generate a communication attribute parameter set including a standardized service type, a standardized delay tolerance, and a standardized reliability level; Based on the communication attribute parameter set, the standardized delay tolerance and the standardized reliability level are jointly analyzed to construct a communication stability requirement vector. The communication stability requirement vector includes a delay threshold, a minimum confirmation period, and a maximum loss tolerance, which is used to characterize the scheduling sensitivity characteristics of the task; Based on the communication stability requirement vector and the standardized service type, searching a task template database for a preset template fragment that is consistent with the standardized service type and matches the scheduling sensitivity feature, extracting structure fields in the template fragment, including a task identification field, a scheduling level field, and a transmission path indication field, to generate an intermediate label structure; Structural fusion of the intermediate tag structure and the communication attribute parameter set, supplementing the task identification field and the scheduling level field in the intermediate tag structure so that it has the ability to uniquely identify the current communication task, and outputting the fused communication task tag draft; The draft communication task label is input into the label integrity verification module, and the final communication task label is generated according to the task uniqueness rule of the current transaction context.

4. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: Obtain status data of the current 5G network environment, including channel quality indicator value, uplink and downlink average delay, available bandwidth and congestion level, and construct a network status feature vector based on the status data, including: Continuously collect channel quality indicator values, uplink average delay, downlink average delay, available bandwidth, and congestion level at fixed time intervals, and add a timestamp to each set of status data as the data record for the current sampling period; Perform sliding window processing on each type of state data over multiple consecutive sampling periods, extract the average value, maximum offset, and change rate of the state data, and calculate the sampling stability factor based on this. The sampling stability factor is used to measure the degree of fluctuation of the state data within the time period; Combine each type of state data with the corresponding sampling stability factor, identify abnormal data items whose change rate exceeds a preset threshold, and assign a set of stability weights to each type of state data; Based on the stability weight and the original state data, a weighted average is performed on the channel quality indicator value, the average uplink delay, the average downlink delay, the available bandwidth, and the congestion level to obtain a weighted state data set with time consistency and noise suppression capabilities; The weighted status data set is organized into a unified structure format according to a preset field sequence, and a network status feature vector including a channel quality indicator value, an uplink average delay, a downlink average delay, available bandwidth, and a congestion level is generated.

5. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: The step of inputting the communication task label and the network state feature vector into a protocol mapping decision graph to generate a protocol reconstruction instruction includes: Constructing a structured input pair, concatenating the standardized service type, standardized delay tolerance, and standardized reliability level in the communication task label with the channel quality indicator value, uplink average delay, downlink average delay, available bandwidth, and congestion level in the network status feature vector in field-level order to form a feature fusion sequence; Based on the feature fusion sequence, a set of candidate protocol paths that fully match the service type field and satisfy the latency constraint and have a bandwidth matching degree greater than a threshold are retrieved from a preset protocol mapping decision graph, wherein each item in the protocol path set corresponds to a set of protocol module loading sequences; Performing a resource adaptability score on each protocol module loading sequence in the candidate protocol path set, wherein the resource adaptability score is calculated and generated based on the idleness, loading overhead, and unloading delay of each protocol module in the current protocol stack resource pool; Select the protocol module loading sequence with the highest resource adaptability score as the target protocol path loading plan, and set a path adaptation flag for each protocol module involved in the target protocol path loading plan. The path adaptation flag is used to indicate whether the module is currently active and needs to be reconfigured; Based on the target protocol path loading plan and the path adaptation identifier, a protocol reconstruction instruction is generated. The protocol reconstruction instruction includes a list of modules to be loaded, a list of modules to be unloaded, and configuration parameter mapping rules, which are used to control the dynamic reconstruction operation of the protocol modules in the protocol stack resource pool.

6. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: The step of loading or unloading at least one protocol module from the protocol stack resource pool according to the protocol reconstruction instruction to construct a protocol path that meets the requirements of the communication task label and the network state feature vector, and assigning a transaction identifier to each protocol path, includes: Performing a field-level difference comparison between the list of modules to be loaded in the protocol reconstruction instruction and the set of modules already loaded in the current protocol stack to generate a module loading plan difference set for indicating the protocol modules that need to be newly loaded; For each protocol module in the module loading plan difference set, according to its required dependent module list and context initialization parameter rules, all directly dependent and indirectly dependent modules are retrieved and marked from the protocol stack resource pool to build a recursive loading dependency chain; Module loading is performed according to the calling order between modules in the recursive loading dependency chain. During the loading operation, module context parameters are initialized and interconnected according to the configuration parameter mapping rules defined in the protocol reconstruction instructions. After all target protocol modules are loaded, a protocol path fingerprint is generated based on the current communication task label and the network status feature vector. The protocol path fingerprint is then compared with the historical path fingerprint library in the resource pool to determine whether a similar path structure exists. If no match is found, a unique transaction identifier is created and the path structure is registered in the path index table. The transaction identifier is bound to the currently constructed protocol path, and a protocol path status descriptor is generated. The protocol path status descriptor includes the operating status, context activity status and most recently used timestamp of each module in the path, which is used as a reference for subsequent data scheduling and resource recovery.

7. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: The step of establishing a transaction-level data buffer based on the transaction identifier, dividing the data to be transmitted into a plurality of data packets and writing the data packets into the transaction-level data buffer, and marking each data packet with a priority tag corresponding to the communication task tag, includes: After binding the transaction identifier to the currently constructed protocol path, generating a structured data partitioning parameter set based on the maximum bearer unit length and supported fragment structure of each protocol module in the protocol path, and using the structured data partitioning parameter set as a basis for data partitioning configuration; performing length-controlled segmentation on the data to be transmitted based on the structured data segmentation parameter set, and appending the transaction identifier, sequence number, and checksum tag to each segmented segment to form a set of data packets to be buffered, wherein the set of data packets to be buffered serves as a target object for writing into the transaction-level data buffer; Extracting the standardized service type, standardized delay tolerance, and standardized reliability level from the communication task tag, generating a unique priority tag for each data packet in the set of data packets to be buffered according to a priority coding rule table bound to the three extracted fields, and embedding the priority tag into a control field of the data packet; Based on the priority tag and current free space information of the transaction-level data buffer, a cache slot dynamic allocation operation is performed to determine the storage location of each data packet to be buffered in the transaction-level data buffer, and a buffer scheduling index table is generated to indicate the processing order between packets; According to the buffer scheduling index table, a transaction-level data buffer queue structure is established with the priority tag as a scheduling keyword, and the transaction-level data buffer queue structure is used as a transaction-level data buffer area.

8. The adaptive protocol stack reconstruction and transaction-level data control method for 5G communication according to claim 1, characterized in that: The performing of a dynamic flow control operation according to the network state feature vector and the priority label includes: Calculating a target transmission rate cap based on the available bandwidth field and the congestion level field in the network state feature vector, where the target transmission rate cap is used to limit the data output rate of the current transaction-level data buffer, specifically comprising: constructing a transmission suppression factor based on the available bandwidth field and the congestion level field, and applying the transmission suppression factor to a basic rate configuration of the transaction-level data buffer to generate a rate control parameter set; Combining the priority tag of each data packet to be transmitted in the transaction-level data buffer with the rate control parameter set, performing data packet rate scheduling calculation, and generating a scheduling weight sequence, wherein the scheduling weight sequence is used to describe the importance ranking of each data packet relative to the transaction priority tag under the current target transmission rate upper limit constraint; Constructing a scheduling priority queue according to the scheduling weight sequence, wherein the scheduling priority queue arranges data packets from high to low according to the scheduling weight value and serves as a candidate transmission sequence for the current scheduling period; Based on the uplink average delay field and the downlink average delay field in the network state feature vector, combined with the current free capacity of the transaction-level data buffer, the window capacity upper limit of the current scheduling period is dynamically determined, and the window capacity upper limit is used to intercept the first several data packets within the window size range from the scheduling priority queue to form a flow control packet output plan; Each data packet in the flow control packet output plan is encapsulated into a transmission queue, and a transaction identifier and a path adaptation identifier are attached during the encapsulation process. The path adaptation identifier is derived from the context activity state of the corresponding protocol module in the protocol path, and is used to perform path-level confirmation and sequence reconstruction operations at the receiving end, and the transmission queue is submitted to the link interface for output scheduling.

Images