Service-based wireless Internet of Things terminal adaptive channel competition and scheduling method

Abstract

The invention relates to the technical field of data transmission, and discloses a service-based wireless Internet of Things terminal adaptive channel competition and scheduling method, which comprises the following steps of: after service data is acquired, matching service priority, processing data volume and resource calling volume; determining a first channel competition coefficient based on the service priority, marking a to-be-selected channel, and calculating a second channel competition coefficient by combining the average data volume and the average call volume of the service data in the to-be-selected channel; and weighting to obtain a comprehensive competition coefficient, selecting a final channel according to the sequence, and selecting a channel of which the transmission frequency is lower than a reference value if the difference is equal. According to the method, service differentiation self-adaptive scheduling is realized, the transmission quality of high-priority services is guaranteed preferentially, the channel conflict probability is effectively reduced, the utilization rate of wireless spectrum and channel resources is improved, and the network transmission efficiency and reliability are optimized.

Description

Technical Field

[0001] This application relates to the technical field of data transmission, and in particular to a service-based adaptive channel contention and scheduling method for wireless Internet of Things (IoT) terminals. Background Technology

[0002] The application of IoT technology in industries, people's livelihoods, smart cities and other fields continues to deepen. The deployment scale of wireless IoT terminals is growing explosively, the number of connected devices is increasing day by day, and heterogeneous business scenarios are constantly emerging. Different businesses have different service requirements for data transmission latency, reliability and throughput.

[0003] As a non-renewable and precious resource, the efficiency of the allocation and utilization of wireless spectrum directly determines the communication performance of wireless Internet of Things. Currently, multiple wireless communication technologies such as WiFi, Bluetooth, and Zigbee coexist in unlicensed frequency bands, and the interference between devices caused by the interweaving of heterogeneous networks is becoming increasingly prominent. Especially in scenarios with high-density terminal deployment, the competition for spectrum resources is becoming increasingly fierce, which directly leads to a significant increase in the probability of channel collisions, a sharp decline in the overall network throughput, and a continuous increase in data transmission latency.

[0004] Currently, most existing channel scheduling methods for wireless IoT adopt a simple time-division multiplexing mode. This mode does not differentiate between the actual data throughput and resource usage requirements of different functional modules or services, and assigns the same channel access priority to all modules or services. This results in high-throughput, high-resource-demand services not being able to obtain appropriate channel resource support, while low-demand services occupy some channel resources, causing waste. Furthermore, the lack of targeted channel competition strategies makes it impossible to dynamically adjust scheduling rules according to actual service needs, resulting in an overall channel resource utilization rate that needs to be improved, making it difficult to balance service transmission efficiency with the rationality of resource allocation. Summary of the Invention

[0005] To improve the utilization rate of channel resources, this application provides a service-based adaptive channel contention and scheduling method for wireless IoT terminals, employing the following technical solution: A service-based adaptive channel contention and scheduling method for wireless IoT terminals includes the following steps: Acquire business data, match the corresponding business priority from the preset priority database based on the business data, identify the data content of the business data, and match the corresponding processing data volume and resource call volume from the preset processing database based on the data content; Based on service priority, a first channel contention coefficient is matched. Based on the first channel contention coefficient, the priority of the transmission channel is matched to the service data. The priority of the transmission channel corresponds to the first channel contention coefficient. Based on the priority of the transmission channel, the corresponding transmission channel is marked as a candidate channel. All service data in the candidate channels are obtained, and the amount of computational data and resource call volume corresponding to each service data are obtained. The average data volume is calculated based on the average value of the calculated data volume of all business data, and the average resource call volume is calculated based on the average value of the calculated data volume. The data ratio is obtained based on the ratio of the calculated data volume to the average data volume, and the resource ratio is obtained based on the ratio of the resource call volume to the average call volume. The second channel contention coefficient is calculated based on the data ratio and the resource ratio. The comprehensive competition coefficient is calculated based on the first channel competition coefficient and the second channel competition coefficient, wherein the weight of the first channel competition coefficient is greater than the weight of the second channel competition coefficient. Based on the comprehensive competition coefficient, each transmission channel in the candidate channels is sorted, and the transmission channel with the highest ranking is selected as the final channel, through which the service data is sent. If the comprehensive competition coefficient is the same in multiple transmission channels, the transmission frequency of the service data task in each transmission channel is calculated, and the transmission channel with a transmission frequency lower than the preset frequency reference value is selected as the final channel.

[0006] By adopting the above technical solutions, through service priority matching, quantitative evaluation of data volume and resource call volume, hierarchical calculation of comprehensive competition coefficient, and combined with transmission frequency-assisted decision-making, differentiated allocation and dynamic adaptive scheduling of channel resources for services can be achieved. This not only prioritizes the channel resources and transmission quality of high-priority services, but also avoids low-demand services from ineffectively occupying spectrum resources, effectively reducing the probability of channel conflicts in high-density heterogeneous terminal scenarios, significantly improving the overall utilization rate of wireless spectrum and channel resources, and taking into account the differentiated needs of different services in terms of latency, reliability, and throughput, thus optimizing network transmission efficiency and the rationality of resource allocation.

[0007] Furthermore, the step of marking the corresponding transmission channel as a candidate channel according to the priority of the transmission channel also includes the following steps: Obtain the transmission load in the transmission channel corresponding to each priority, calculate the ratio of transmission load to total load as the transmission occupancy rate, and calculate the transmission idle rate = 1 - transmission occupancy rate; If the number of candidate channels is greater than the preset reference number, the candidate channels are sorted according to the transmission idle rate, and the last set number of candidate channels are marked. The average idle rate is calculated by taking the average idle rate of the remaining candidate channels, and the set quantity is adjusted according to the positive correlation of the average idle rate.

[0008] By adopting the above technical solution, the transmission load and idle rate of different priority transmission channels can be monitored in real time, and the set of candidate channels can be filtered and simplified as needed, avoiding scheduling redundancy and decision inefficiency caused by too many candidate channels. At the same time, the number of channels to be filtered can be adaptively adjusted based on the average idle rate of the remaining candidate channels, which can dynamically adapt to changes in network load and prioritize the retention of high-quality channels with high idle rates and low congestion.

[0009] Furthermore, the method also includes the following steps: Calculate the uniformity of the transmission idle rate distribution of the candidate channels, and calculate the uniformity comparison value based on the uniformity of the distribution and the preset reference uniformity. The idle rate is calculated based on the average idle rate and the preset reference idle rate. The channel condition comparison value is calculated based on the uniform comparison value and the idle comparison value. The weight of the first channel contention coefficient is adjusted according to the negative correlation of the channel condition comparison value.

[0010] By adopting the above technical solutions, in harsh network scenarios with scarce channel idle resources and uneven state distribution, the priority weight ratio of services can be automatically increased, the channel contention guarantee capability of high-priority services can be strengthened, and the weight allocation can be reasonably balanced when the channel conditions are good, so as to achieve adaptive matching between the channel contention strategy and the real-time network conditions.

[0011] Furthermore, the method also includes the following steps: The final channel corresponding to the service data with the same priority is the historical channel. The number of channel numbers of the historical channels is the channel quantity. The ratio of the channel quantity to the total number of all transmission channels is the median value of the channel quantity. Business data with the same source, priority, and content attributes are considered to be of the same source. The number of times the same source business data calls the transmission channel is the total number of transmissions. The number of times the same source business data changes the final channel is the number of changes. The ratio of the number of changes to the total number of transmissions is the median value of the channel changes. The intermediate value of channel call is calculated based on the median value of the number of channels and the median value of channel transformation; The adjustment speed of the weight of the first channel contention coefficient is controlled by the positive correlation between the channel call median value and the control.

[0012] By adopting the above technical solution, the speed of weight adjustment can be dynamically adapted to the actual channel calling habits of the business, which can avoid scheduling instability caused by frequent and drastic fluctuations in weight, and can quickly respond and adjust when the business channel is used in a dispersed manner and switching is frequent.

[0013] Furthermore, the method also includes the following steps: If the intermediate value of the channel call is greater than the preset maximum value of the channel call, a new channel request will be issued; Based on the request to add a channel, query the channel connection port; If an expandable channel connection port exists, a new transmission channel is requested to be established based on the channel connection port; otherwise, it is returned that no new channel information can be added.

[0014] By adopting the above technical solutions, channel resources can be expanded elastically on demand, effectively alleviating the problems of channel call overload and resource shortage, and ensuring stable service transmission; when there are no expansion ports, timely feedback of the inability to expand is provided, improving the intelligence, initiative and emergency response capability of the system channel scheduling, and further optimizing the reliability and resource guarantee capability of wireless IoT communication.

[0015] Furthermore, the method also includes the following steps: Since it is impossible to add new channel information, service convergence instructions are obtained in real time. If a service fusion instruction is obtained, the service data to be transmitted corresponding to the service fusion instruction is packaged into a complete data packet, and the service data to be transmitted in the final channel of the corresponding service data to be transmitted is taken as the target data. The service data to be transmitted corresponding to the service fusion instruction is then merged at the end of the target data. After transmission is complete, the target data and the complete data packet are separated from the received business data, and the complete data packet is restored to the business data.

[0016] By adopting the above technical solutions, the data carrying capacity and transmission efficiency of a single channel can be effectively improved without adding new transmission channels, alleviating the transmission congestion problem caused by insufficient channel resources, ensuring stable and continuous transmission of various service data, and greatly improving the system's adaptive scheduling capability and utilization efficiency of existing spectrum resources when channel resources are scarce.

[0017] Furthermore, the method also includes the following steps: Service convergence instructions include service licensing instructions and channel licensing instructions; First, trigger the business license information, then obtain the business license key from the input terminal based on the business license information. If the business license key matches the preset key database, then generate a business license instruction. Based on the generated service license instruction, the channel license information is triggered. Based on the channel license information, the channel operation license is read from the preset line. If the content of the channel operation license is a convergence license, then a channel license instruction is generated. Service convergence instructions are generated and sent based on service license instructions and channel license instructions.

[0018] By adopting the above technical solutions, problems such as unauthorized service access and irregular channel fusion can be effectively avoided, significantly improving the security and controllability of the data fusion process. At the same time, it ensures that the service fusion operation strictly follows the preset permissions and channel status, forming a closed-loop verification with the overall channel scheduling and data fusion process, ensuring stable and reliable system operation and standardized scheduling order.

[0019] Furthermore, the method also includes the following steps: The queue that acquires the existing service data in the final channel is called the service queue; Get the data volume of business data in the business queue and sort the data volume; The business data with the lowest data volume is selected as the target data; or, n adjacent business data are selected as a business group, the sum of the data volume in the business group is calculated, and the business data with the lowest data volume in the business group with the lowest sum is selected as the target data.

[0020] By adopting the above technical solutions, the interference of data fusion on the original service transmission can be minimized, the channel load pressure and transmission delay fluctuations can be reduced, and the system can adapt to service queue scenarios of different lengths and densities, improve the rationality and adaptability of data fusion operations, and further improve the transmission carrying efficiency and channel resource utilization of a single channel.

[0021] Furthermore, the method also includes the following steps: Based on the data content, the corresponding processing time data is matched from the preset time database; The impact of timeliness is calculated based on the processing timeliness data and the preset timeliness correspondence value; The weight of the second channel competition coefficient is adjusted according to the positive correlation between the timeliness impact value and the timeliness impact value.

[0022] By adopting the above technical solutions, it is possible to match the corresponding timeliness parameters according to the timeliness requirements of business data processing, quantify the degree of timeliness impact and dynamically adjust the weight of the second channel competition coefficient, so that the channel scheduling strategy is highly adapted to the timeliness requirements of the business, prioritize the channel competition capability of high timeliness and latency-sensitive businesses, and further strengthen the differentiated scheduling of the timeliness dimension while taking into account the data volume and resource call requirements.

[0023] Furthermore, the method also includes the following steps: A business feedback task is triggered after successful business data transmission. Based on the business feedback task, obtain feedback information and extract transmission quality values ​​from the feedback information; The percentage change trend is calculated based on multiple transmission quality values, and the adjustment speed of the weight of the second channel competition coefficient is controlled according to the negative correlation of the percentage change trend.

[0024] By adopting the above technical solutions, the pace of weight adjustment can be slowed down when transmission quality fluctuates drastically, avoiding scheduling instability caused by frequent parameter changes. When transmission quality is stable, adaptive adjustment can be accelerated, improving the response efficiency of channel scheduling and achieving dynamic adaptation between weight adjustment and actual transmission quality. Attached Figure Description

[0025] Figure 1 This is a step diagram of a service-based adaptive channel contention and scheduling method for wireless IoT terminals.

[0026] Figure 2 This is a diagram illustrating the steps of marking corresponding transmission channels as candidate channels based on their priority. Detailed Implementation

[0027] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.

[0028] This application discloses a service-based adaptive channel contention and scheduling method for wireless IoT terminals, referring to... Figure 1 It includes the following steps: S100: Obtain business data and match business priorities, data volume, and resource usage. The channel scheduling core node collects the service data to be transmitted uploaded by each wireless IoT terminal in real time. The service data covers heterogeneous service types such as industrial control, public monitoring, and smart city sensing. Different services have different transmission requirements in terms of latency, reliability, and throughput.

[0029] This system is pre-configured with a priority database, which contains a one-to-one mapping between different service types, service scenarios, and service priorities. The priority value is positively correlated with the importance of the service and the transmission assurance level; that is, the higher the priority value, the higher the transmission assurance requirements. The channel scheduling core node parses the service data, identifies its service type, transmission scenario, service level, and other data content, and performs a matching query in the priority database based on the identification results to determine the service priority corresponding to the current service data.

[0030] Meanwhile, the system is pre-configured with a processing database that stores the mapping relationship between the amount of processed data and the amount of resource calls corresponding to different data content, data packet formats, and service types. The amount of processed data refers to transmission volume parameters such as the size of the data packets and the bit length required for service data transmission, while the amount of resource calls refers to system resource parameters such as terminal computing power, channel bandwidth, and signal power required for service data transmission, parsing, and forwarding. The channel scheduling core node accurately matches the identified service data content in the processing database to obtain the amount of processed data and the amount of resource calls corresponding to the current service data, thus completing the quantitative characterization of the basic attributes of the service.

[0031] S200: Determine the first channel contention coefficient and filter candidate channels, and collect service data parameters within the candidate channels: The system pre-configures a positive correlation between service priorities and the first channel contention coefficient. Higher service priorities correspond to a larger first channel contention coefficient, indicating stronger contention and preemption capabilities for the service on the transmission channel. The channel scheduling core node obtains the first channel contention coefficient by calling the corresponding table based on the service priorities determined by S100.

[0032] The priority of the transmission channel is directly linked to the first channel contention coefficient. The higher the first channel contention coefficient, the higher the priority of the matched transmission channel. The channel scheduling core node uses the transmission channel priority as the screening basis, and marks the transmission channels with priorities that reach the preset threshold as candidate channels to complete the initial screening of the channel pool, narrow the scope of subsequent scheduling decisions, and improve scheduling efficiency.

[0033] After the candidate channels are marked, the channel scheduling core node traverses each candidate channel in real time, collects all service data currently in the buffer queue and being transmitted within the channel, and extracts the amount of computational data required for the actual transmission and the amount of resource calls used by the system for each service data item, providing real-time and accurate service data support for the objective calculation of the subsequent channel contention coefficient.

[0034] S300: Calculate the mean parameter and determine the second channel contention coefficient based on the ratio: The channel scheduling core node performs an arithmetic average calculation on the calculated data volume of all service data in the candidate channel collected by S200 to obtain the average data volume, which represents the average transmission volume of the overall service of the candidate channel; at the same time, it performs an arithmetic average calculation on the resource call volume of all service data to obtain the average call volume, which represents the average resource occupancy level of the overall service of the candidate channel.

[0035] For each individual service data item within the candidate channel, calculate the ratio of its calculated data volume to the average data volume, denoted as the data ratio. The larger the data ratio, the larger the data transmission volume of the service. Calculate the ratio of its resource usage volume to the average usage volume, denoted as the resource ratio. The larger the resource ratio, the higher the resource consumption requirement of the service data.

[0036] The channel scheduling core node calculates the data ratio and resource ratio by fusing them according to preset calculation rules (such as weighted summation and normalized product) to obtain the second channel competition coefficient. The second channel competition coefficient is based on the actual transmission volume and resource occupation requirements of the service, and realizes a quantitative assessment of the objective resource requirements of the service, serving as an auxiliary decision-making basis for channel competition.

[0037] S400: Weighted calculation of overall competitiveness coefficient, with a priority-based weighting strategy. The core node of channel scheduling uses a weighted fusion method to calculate the comprehensive competition coefficient, and the system has a preset weight allocation rule: the weight of the first channel competition coefficient is greater than the weight of the second channel competition coefficient. Service priority is the core leading factor to ensure the priority scheduling authority of high-level and high-security services. At the same time, the second channel competition coefficient is used as an auxiliary adjustment factor to take into account the rationality of the actual data volume and resource requirements of the service.

[0038] The comprehensive competition coefficient integrates three dimensions of characteristics: service priority, data transmission volume, and resource usage volume. It comprehensively and objectively represents the overall channel competitiveness of current service data, providing a unified quantitative evaluation index for subsequent channel ranking and selection.

[0039] S500: The final channel is selected based on the comprehensive competition coefficient ranking, and the transmission frequency is used to assist in the decision-making process for equal channel allocation. The channel scheduling core node sorts the comprehensive competition coefficient of the current service data in descending order among the candidate transmission channels. The larger the comprehensive competition coefficient, the higher the ranking. The candidate transmission channel with the highest ranking is selected as the final channel, and the service data is scheduled to be transmitted to the final channel to complete the transmission, thus achieving adaptive matching of the optimal channel.

[0040] If multiple transmission channels have the same comprehensive competition coefficient ranking and the final channel cannot be directly selected, the channel scheduling core node further counts and calculates the transmission frequency of service data tasks within each shared transmission channel. The transmission frequency is the number of times the channel completes service data transmission per unit time, which directly reflects the channel's busyness and congestion status.

[0041] The system pre-configures frequency reference values. The channel scheduling core node compares the transmission frequency of each shared transmission channel with the frequency reference value and selects the transmission channel with a transmission frequency lower than the preset frequency reference value and a lower degree of congestion as the final channel. This further avoids high-congestion channels, reduces transmission conflicts and delay risks, and improves transmission stability.

[0042] Furthermore, after marking the corresponding transmission channels as candidate channels according to their priority in step S200, this embodiment also sets up an adaptive filtering and dynamic adjustment step based on transmission load and transmission idle rate to further optimize the candidate channel set and eliminate channels with severe congestion and low scheduling value. This includes the following sub-steps: S201 collects transmission load and calculates transmission occupancy rate and transmission idle rate: The channel scheduling core node collects the transmission load of each priority-marked transmission channel in real time. The transmission load is the ratio of the total amount of service data queued, waiting to be transmitted, and being transmitted in the current channel to the channel's rated maximum capacity, which is used to quantitatively characterize the busyness of a single channel. At the same time, the total load of all transmission channels with the same priority in the system is calculated and recorded as the total load.

[0043] For each transmission channel, the channel scheduling core node calculates the transmission occupancy rate and transmission idle rate using the following formulas: Transmission occupancy rate = Transmission load of a single transmission channel / Total load; Transmission idle rate = 1 - Transmission occupancy rate; where the transmission idle rate is positively correlated with the available resources of the channel and the smoothness of transmission. The higher the transmission idle rate, the more abundant the remaining resources of the channel and the lower the degree of channel congestion, making it more suitable for allocating new service data for transmission.

[0044] S202 determines whether to perform simplified filtering of candidate channels based on the reference quantity: The system pre-configures a reference quantity, which is the upper limit threshold of the optimal candidate channels to ensure channel scheduling efficiency. The reference quantity is preset by the system based on the deployment density of wireless IoT terminals, the total amount of spectrum resources, and the service concurrency.

[0045] The channel scheduling core node counts the total number of candidate channels that have been marked in real time. If the number of candidate channels is less than or equal to the preset reference number, it indicates that the current candidate channel scale is appropriate and does not need to be simplified. The process can directly proceed to the subsequent second channel competition coefficient calculation process. If the number of candidate channels is greater than the preset reference number, it indicates that the candidate channel set has too much redundancy, which can easily increase the scheduling calculation overhead and reduce the decision response speed. Therefore, the candidate channel simplification and screening operation needs to be performed.

[0046] S203 sorts and eliminates inferior candidate channels based on transmission idle rate: The channel scheduling core node sorts all candidate channels in descending order of their transmission idle rate. The higher the transmission idle rate, the higher the channel is ranked, indicating a better channel resource status. Channels ranked lower have low transmission idle rates, high congestion levels, scarce channel resources, and lower scheduling value.

[0047] The system pre-configures a set number of low-quality candidate channels to be eliminated in this screening. The channel scheduling core node selects the set number of candidate channels at the end of the sorting, cancels their "candidate channel" mark, and removes them from the candidate channel set. Only the high-quality channels with higher ranking and higher transmission idle rate are retained as valid candidate channels for subsequent scheduling. This reduces the size of candidate channels, decreases the computational load of subsequent coefficient calculation and channel sorting, and improves the efficiency of channel scheduling response.

[0048] S204 calculates the average idle rate and dynamically adjusts the set quantity accordingly: After eliminating inferior channels, the channel scheduling core node calculates the arithmetic mean of the transmission idle rates of all remaining valid candidate channels to obtain the average idle rate. The average idle rate is used to quantitatively characterize the overall resource idle status of the current set of remaining candidate channels. The higher the average idle rate, the more abundant the available resources of the overall candidate channels and the lighter the network load; the lower the average idle rate, the more congested the overall candidate channels and the greater the network load pressure.

[0049] In this embodiment, the quantity is set to be positively correlated with the average idle rate, and the specific adjustment rules are as follows: When the average idle rate is higher than the first preset idle threshold, it indicates that the overall candidate channel resources are sufficient and the congestion risk is low. The set number can be appropriately increased to allow more channels with lower rankings to be eliminated at once, further simplifying the candidate channel set and maximizing scheduling efficiency. The set number = system default initial value × k1; k1 is the amplification factor, with a value range of 1.2 to 2.0, and 1.5 is preferred in this embodiment.

[0050] When the average idle rate is between the first preset idle threshold and the second preset idle threshold, it indicates that the overall candidate channel resource status is moderate. The set number is kept at the system default initial value to maintain a stable screening and elimination scale. When the average idle rate is lower than the second preset idle threshold, it indicates that the overall candidate channels are generally congested and available resources are scarce. Therefore, the set number needs to be reduced to decrease the number of channels eliminated in a single operation, retaining as many available channels as possible. This avoids insufficient candidate channels due to excessive elimination, which would prevent meeting the competition and scheduling requirements of service channels. The set number = system default initial value × k2; where k2 is a reduction coefficient, ranging from 0.3 to 0.8, and preferably 0.5 in this embodiment.

[0051] Through the above closed-loop adjustment logic, the set number can be adaptively adjusted in real time according to the overall idle state of the network, so that the selection scale of candidate channels can be accurately matched with the actual load and channel resource status of the current wireless IoT.

[0052] After the adaptive adjustment of the set number is completed in step S204, in order to adapt the weight of the first channel contention coefficient to the overall operating conditions of the candidate channels, this embodiment further adds a channel operating condition quantification evaluation and weight dynamic adjustment process as steps S205~S209, which are implemented as follows: S205: Define parameters and retrieve historical calculation results: Using the parameters determined in the previous steps: Number of remaining valid candidate channels: Nremain; Idle rate of a single candidate channel: η1, η2, ..., ηNremain; Average idle rate of candidate channels: Taken from S204, this step calculates the distribution characteristics of the channel idle state based on the above parameters, providing basic data for operational condition assessment.

[0053] S206: Calculate the uniformity of the distribution of idle rate of the candidate channel (DU): Distribution uniformity (DU) is used to quantify the balance of idle rates among candidate channels. A lower value indicates a more uneven distribution. The specific calculation process is as follows: Calculate the overall standard deviation σ of the transmission idle rate, which characterizes the degree of dispersion of the idle rate of each channel from the average value: The distribution uniformity DU is defined using a normalization method, with a value range of [0, 1]: DU = 1 - σ / ηavg; when σ = 0, all channels have the same idle rate, and DU = 1 (most uniform distribution); when σ approaches ηavg, DU approaches 0 (most non-uniform distribution).

[0054] S207: Calculate the uniform contrast value Kuni and the idle contrast value Kidle: (1) Configure preset reference parameters: The system is pre-configured with two benchmark parameters, which are calibrated by technicians based on the deployment density of IoT terminals and service types: Reference uniformity DU-ref: the threshold for the uniformity of ideal channel idle rate distribution, with a value range of 0.7~0.9, preferably 0.8 in this embodiment; Reference idle rate ηref: the benchmark idle rate threshold for sufficient channel resources, with a value range of 0.4~0.6, preferably 0.5 in this embodiment.

[0055] (2) Calculate the uniform contrast value Kuni: The uniformity comparison value characterizes the degree of deviation of the actual distribution uniformity from the ideal state. The calculation formula is: Kuni=DU / DU-ref. If Kuni<1: the actual uniformity is lower than the reference value, and the channel idle state distribution is uneven. If Kuni≥1: the actual uniformity reaches or is better than the reference value, and the channel idle state is balanced.

[0056] (3) Calculate the idle comparison value Kidle: The idle ratio represents the sufficiency of the actual average idle rate relative to the reference level. The calculation formula is: Kidle = ηavg / ηref. If Kidle < 1, the actual idle rate is lower than the reference value, and the channel resources are tight. If Kidle ≥ 1, the actual idle rate reaches or exceeds the reference value, and the channel resources are sufficient.

[0057] S208: Calculate the channel condition comparison value Kwork: The channel condition comparison value is a weighted fusion result of the uniformity comparison value and the idleness comparison value, which comprehensively characterizes the overall channel condition. The calculation formula is: Kwork=ω1×Kuni+ω2×Kidle; where: ω1: uniformity weighting coefficient, with a value of 0.4~0.6, and 0.5 in this embodiment; ω2: idleness weighting coefficient, with a value of 0.4~0.6, and 0.5 in this embodiment; constraint condition: ω1+ω2=1, to ensure the normalization of the fusion result; physical meaning: the smaller Kwork is, the worse the channel condition (low idleness and uneven distribution); the larger Kwork is, the better the channel condition.

[0058] S209: Weight w1 for adjusting the first channel contention coefficient based on Kwork negative correlation: (1) Initial weight configuration: The system presets the initial weights: the initial weight of the first channel contention coefficient w1 is 0.6~0.7, and 0.65 is preferred in this embodiment; the initial weight of the second channel contention coefficient w2 is 0.3~0.4, and 0.35 is preferred in this embodiment; the constraint condition is w1+w2=1, and w2=1-w1 is updated synchronously when adjusting the weights.

[0059] (2) Configure adjustment parameters and thresholds: Weight adjustment step size Δw: 0.1~0.2, preferably 0.15 in this embodiment; good working condition threshold KH: 1.0 (good working condition is when Kwork≥KH); bad working condition threshold KL: 0.6 (bad working condition is when Kwork≤KL).

[0060] (3) Segmented quantification adjustment rules: The system employs a negative correlation adjustment logic (the smaller Kwork is, the larger w1 is), and is implemented in three intervals: Severe operating conditions (Kwork≤KL): Channel idle rate is low and extremely unevenly distributed, resources are scarce, so the priority weight is significantly increased: w1 = initial w1 + Δw × (KL - Kwork) / KL; after adjustment, w1 ≤ 0.85 (to avoid excessive weight leading to rigid resource allocation); Medium operating conditions (KL < Kwork < KH): Channel conditions are moderate, maintaining the initial weight, with only slight stabilization: w1 = initial w1; Good operating conditions (Kwork≥KH): Channel idle is sufficient and evenly distributed, so the priority weight is appropriately reduced to balance resource demand: w1 = initial w1 - Δw × (Kwork - KH) / KH; after adjustment, w1 ≥ 0.5, always ensuring the dominant position of service priority.

[0061] (4) Application of adjustment results: The adjusted w1 is directly used for the calculation of the comprehensive competition coefficient in subsequent steps S300~S400, realizing real-time adaptation of weights to channel conditions.

[0062] After completing the adaptive adjustment of the first channel contention coefficient weight based on the aforementioned step S209, in order to ensure that the weight adjustment speed conforms to the actual channel calling habits of the service and avoid frequent fluctuations or response lag, this embodiment further adds a historical channel calling feature quantification and weight adjustment speed control process as steps S210~S213, which are implemented as follows: S210: Acquire historical channel data and calculate the median value of the number of channels: (1) Historical channel filtering: The channel scheduling module selects all historical service data with the same priority as the current service data from the preset historical scheduling database, extracts the final channel selected when transmitting this type of historical service data, and denots it as the historical channel set {C1, C2, ..., Cm}, where m is the total amount of historical service data.

[0063] (2) Parameter definition and calculation: Define the number of channels Nhist: the total number of unique channel numbers in the historical channel set, i.e., the number of independent channels used by this priority service; define the total number of transmission channels Ntotal_chan: the total number of all available transmission channels in the system (using the previous definition, a fixed preset value); calculate the median value of the number of channels Mnum, which characterizes the degree of dispersion of the historical channel usage range of services of the same priority, calculated by the formula: Mnum = Nhist / Ntotal_chan; physical meaning: Mnum ∈ [0, 1], the larger the value, the wider the range of channels used and the more dispersed the distribution of services of the same priority in the past; the smaller the value, the more concentrated the service is on a few channels.

[0064] S211: Filter source service data and calculate intermediate channel transformation values: (1) Definition of business data from the same source: Define common source business data as: a set of historical business data {D1, D2, ..., Dk} that meets the following criteria: "same source (same wireless IoT terminal), same business priority, same content attributes (e.g., all are environmental monitoring data, equipment control commands, etc.)", where k is the total amount of common source business data.

[0065] (2) Statistics and calculation of key parameters: Total transmission count Ttotal: The cumulative number of times each data in the same source service data set successfully calls the transmission channel, i.e., Ttotal=k; Transition count Tchange: The cumulative number of times the final channel number used in two adjacent transmissions in the same source service data set is different (e.g., if data Di uses channel Ca and data Di+1 uses channel Cb, and Ca≠Cb, then it is counted as 1 transition); Calculate the intermediate value of channel transition Mchange, which characterizes the frequency of channel switching for the same source and type of service. The calculation formula is: Mchange=Tchange / Ttotal; Physical meaning: Mchange∈[0,1], the larger the value, the higher the frequency of channel switching during the transmission of the same source and type of service; the smaller the value, the stronger the channel stability of the service transmission.

[0066] S212: Weighted calculation of intermediate values ​​for channel call: The channel call median value Mcall is the weighted average of the median channel number and the median channel change value, comprehensively representing the channel usage dispersion and handover activity of priority services. The calculation formula is: Mcall = α × Mnum + β × Mchange; where: α is the channel number weighting coefficient, ranging from 0.4 to 0.6, preferably 0.5 in this embodiment, used to balance the influence weight of usage range and handover frequency; β is the channel change weighting coefficient, ranging from 0.4 to 0.6, preferably 0.5 in this embodiment; constraint condition: α + β = 1, to ensure the normalization of the fusion result; physical meaning: Mcall ∈ [0, 1], the larger the value, the more dispersed the channel usage of services of the same priority, the more frequent the handover, and the higher the demand for real-time response to weight adjustment; the smaller the value, the more concentrated the service channel usage, the more stable the handover, and the more frequent the weight adjustment needs to be avoided.

[0067] S213: Controlling the weight adjustment speed based on the positive correlation of the channel call median value: In this step, the "adjustment speed of the weight of the first channel contention coefficient" is defined as: the maximum adjustment range of the weight w1 of the first channel contention coefficient per unit time (denoted as vadj, unit: / s). The adjustment speed is positively correlated with the channel call median value Mcall. The larger Mcall is, the larger vadj is, and the faster the weight adjustment is; conversely, the smaller Mcall is, the slower the adjustment is.

[0068] (1) Adjusting parameter configuration: The system presets the following baseline parameters and thresholds for adjusting speed: Baseline adjustment speed v0: The default base speed for weighted adjustment, ranging from 0.05 to 0.15 / s, preferably 0.1 / s in this embodiment; Fast adjustment threshold MH: The critical value of the intermediate channel call that triggers fast adjustment, ranging from 0.6 to 0.8, preferably 0.7 in this embodiment; Slow adjustment threshold ML: The critical value of the intermediate channel call that triggers slow adjustment, ranging from 0.2 to 0.4, preferably 0.3 in this embodiment; Adjustment speed coefficient kv: Used to quantify the influence of the intermediate value on the speed, ranging from 1.2 to 2.0, preferably 1.5 in this embodiment.

[0069] (2) Segmented quantification adjustment rules: Based on the value range of Mcall, the speed of vadj is controlled and adjusted in three levels, as shown in the following formula: Slow adjustment range (Mcall≤ML): Channels of the same source and type of service are used in concentrated areas with very few handovers. Weight adjustment needs to be stable to avoid fluctuations: vadj=v0 / kv; Example: v0=0.1 / s, kv=1.5, then vadj≈0.067 / s. The weight adjustment range is slowed down to ensure scheduling stability.

[0070] Normal adjustment range (ML < Mcall < MH): Service channel usage and switching are at a moderate level, maintaining the baseline adjustment speed: vadj = v0 to balance response speed and stability, adapting to most normal service scenarios.

[0071] Fast adjustment range (Mcall≥MH): Service channels are used in a dispersed manner and switch frequently, so it is necessary to speed up the weight adjustment to adapt quickly: vadj=v0×kv; Example: v0=0.1 / s, kv=1.5, then vadj=0.15 / s. The weight can respond quickly to changes in channel conditions and avoid adaptation lag.

[0072] (3) Application of speed adjustment: The calculated vadj directly affects the weight adjustment process in step S209: after the new target weight value w1_new is calculated, the actual weight smoothly transitions from the current value w1_curr to w1_new at the rate of vadj, with a transition time ttrans=|w1_new-w1_curr| / vadj, ensuring that the speed of weight adjustment is precisely matched with the calling habits of the service channel.

[0073] After calculating the intermediate channel call value Mcall based on the aforementioned step S212, in order to address the resource shortage caused by the dispersed use of service channels and frequent handovers, and to achieve on-demand elastic expansion of channel resources, this embodiment further adds a channel call over-limit judgment and dynamic expansion process as steps S214~S217, which are implemented as follows: S214: Channel call intermediate value exceeding limit judgment and new channel request triggering: (1) Preset threshold configuration: The system pre-configures a maximum channel call value, Mcall-max. This threshold is the critical value for triggering channel expansion and is used to determine whether the channel call status of services with the same priority or from the same source and of the same type has reached resource saturation. The value range is 0.7 to 0.9, and 0.8 is preferred in this embodiment. Its physical meaning is: when Mcall ≥ Mcall-max, it indicates that the channel usage range of services with the same priority is extremely wide, and the channel switching frequency of services from the same source is extremely high. The existing channel resources can no longer meet the dynamic call requirements of services, and there is a risk of transmission conflicts and delay exceeding limits.

[0074] (2) Limit overrun detection and request triggering: The channel scheduling module compares the intermediate channel call value Mcall calculated in step S212 with the preset Mcall-max: If Mcall ≤ Mcall-max, it indicates that the current channel call status is within a reasonable range, the existing channel resources can meet the service requirements, and no expansion is needed; the module directly proceeds to the comprehensive competition coefficient calculation process in step S300. If Mcall > Mcall-max, it indicates that the service channel usage dispersion and switching frequency have exceeded the system adaptation threshold, the existing channel resources are approaching saturation, and the channel expansion mechanism needs to be activated. The channel scheduling module automatically generates and issues a new channel request. This request includes key information such as request identifier, triggering reason (Mcall exceeding the limit), current service priority, same-source service identifier, and existing channel resource status, which are used as the basis for subsequent port queries and channel establishment.

[0075] S215: Query the channel connection port status based on the request for a new channel: (1) Port query subject and data source: The channel scheduling module sends new channel requests to the port management module. The port management module is responsible for maintaining the full lifecycle status of all channel connection ports in the system, and its core data is stored in a preset port management database. This database contains key parameters such as port number, occupancy status (idle / occupied), supported channel type (physical channel / logical channel), maximum carrying capacity, expansion compatibility, and associated communication link, ensuring the accuracy and comprehensiveness of query results.

[0076] (2) Port query logic and scalable port determination: After receiving a request to add a channel, the port management module performs a query operation according to the following logic: Filter the ports in the port management database that have "occupancy status = idle" to form a candidate set of idle ports; For candidate idle ports, verify whether their "supported channel type" matches the current service data transmission requirements (such as bandwidth, modulation method, and transmission protocol); Verify whether the port's "maximum carrying capacity" meets the average data volume and resource call volume requirements of the current priority service, that is, the port's maximum carrying capacity is ≥ 1.2 times the processing data volume and resource call volume matched in step S100, and reserve redundancy space; If a port simultaneously meets the criteria of "idle state, type matching, and carrying capacity meeting the standard", it is determined to be an expandable channel connection port; if there is no port among the candidate idle ports that meets the above conditions, it is determined to be "no available expandable port".

[0077] The port management module will send the query results (including the expandable port number, port parameters, or no available port identifier) ​​back to the channel scheduling module.

[0078] S216: Establishment of a new transmission channel when an expandable port exists: If the port management module reports "there is an expandable channel connection port", the channel scheduling module will execute the new transmission channel establishment process based on the port information. The specific steps are as follows: Port configuration initialization: The channel scheduling module sends configuration commands to the expandable port to initialize the port communication parameters, including port transmission bandwidth, modulation and demodulation method (such as LoRa, NB-IoT, WiFi6, etc., to match service transmission requirements), channel coding format, communication protocol version, etc., to ensure the communication compatibility of the port with the existing transmission channel; New channel parameter allocation: Assign a unique channel number to the new transmission channel to avoid conflict with existing channels, set channel priority, which corresponds to the first channel contention coefficient of the current service data, follow the priority matching rules of step S200, and configure core parameters such as the rated maximum capacity of the channel and the transmission delay threshold. Channel registration and network access: Register the parameters of the new transmission channel (channel number, priority, port association, carrying capacity, etc.) to the system's transmission channel management database, and update the system's "total number of transmission channels Ntotal_chan", i.e., Ntotal_chan = Ntotal_chan - old + 1, where Ntotal_chan - old is the total number of channels before expansion, ensuring the accuracy of the calculation of "intermediate value of channel quantity Mnum" in subsequent steps; at the same time, connect the new channel to the wireless IoT communication network, complete the establishment of communication links with the channel scheduling module and wireless IoT terminals, and ensure that the terminal can identify and call the channel; Expansion result feedback: The channel scheduling module generates a "channel expansion successful" feedback message, which includes the new channel number, priority, port association information, expansion time, etc., and synchronizes it to the historical scheduling database and port management database to update the relevant status identifiers.

[0079] S217: Feedback when no available expandable port is available: If the port management module reports "no available or expandable ports," meaning all idle ports have type mismatches, insufficient capacity, or compatibility issues, the channel scheduling module directly generates information indicating that no new channels can be added. This information includes key details such as the feedback identifier, the reason for the inability to expand (no available or expandable ports), the current total channel resources, service priority, and intermediate channel call values. This information is fed back to the channel scheduling core module to trigger subsequent service data fusion processes (corresponding to the "service fusion when no new channels can be added" step mentioned earlier); it is also stored in the system log database to provide data support for technical personnel in subsequent port expansion and hardware upgrades.

[0080] Based on the feedback of "unable to add channel information" in step S217 above, in order to ensure stable transmission of service data in resource-constrained scenarios without expanding the channel, this embodiment further adds a service data fusion transmission and restoration process as steps S218~S221. This process is deeply integrated with the previous "target data selection step" and "service fusion dual license verification step", and the specific implementation is as follows: S218: Triggering the business integration instruction acquisition mechanism: (1) Triggering conditions and command source: After receiving the "Unable to add channel information" feedback from step S217, the channel scheduling module automatically triggers the service convergence preparation mechanism and monitors the preset "service convergence instruction issuance interface" in real time. This service convergence instruction is generated by the system's permission verification module, corresponding to the "service convergence instruction dual permission verification step" mentioned above. The generation conditions are: the service permission key matches successfully and the channel operation permission is "allowed to converge", ensuring the legality and security of the convergence operation.

[0081] (2) Command reception and parsing: If the channel scheduling module successfully obtains the service fusion instruction, it parses the instruction and extracts the core information: the identifier of the service data to be transmitted (corresponding one-to-one with the service data to be transmitted in the current scenario where capacity cannot be expanded), the service data priority, the data transmission time limit requirement, and the fusion permission identifier (indicating that it has passed dual verification). If the service fusion instruction is not obtained (e.g., permission verification fails), the service data to be transmitted is added to the channel waiting queue and waits for the next scheduling according to the preset retry mechanism (retrying once every 500ms, and marking it as "transmission pending" after 3 retries) to avoid data loss.

[0082] S219: Packing of service data to be transmitted and merging of target data: (1) Complete data packet construction: The channel scheduling module performs a standardized packaging process for the service data to be transmitted corresponding to the service fusion instruction: It adds a fused data packet header to the service data to be transmitted. The header contains four core fields: fusion identifier (1 byte): a fixed value of 0xAA, used by the receiver to identify the fused data; data length field (4 bytes): records the original number of bytes of the service data to be transmitted, accurate to 1 byte; service identifier field (8 bytes): uniquely identifies the source, type, and priority of the service data, consistent with the service data attributes in step S100; and checksum field (2 bytes): calculates the checksum of the service data to be transmitted using the CRC16 algorithm, used for data integrity verification by the receiver. The service data to be transmitted after adding the header is then encapsulated into a complete data packet, ensuring that the data structure is standardized and parsable.

[0083] (2) Target data selection and fusion execution: The channel scheduling module calls the execution result of the previous "target data selection step" to determine the target data to be transmitted in the current final channel (the transmission channel selected in step S500). The specific selection logic follows the previous specification: Typical scenario: Select the service data with the lowest data volume in the final channel service queue as the target data; In scenarios with dense business queues: Divide adjacent n business data (n is a preset positive integer, ranging from 2 to 5, with 3 being preferred in this embodiment) into business groups, calculate the data volume and value of each business group, and select the business data with the lowest data volume in the business group with the lowest sum as the target data.

[0084] Once the target data is determined, the channel scheduling module performs a data fusion operation: directly appending the complete data packet to the end of the target data to form a fused transmission unit consisting of "target data + complete data packet". The fused data structure is: [target data header][target data body][fused data packet header][service data body to be transmitted][fused data packet checksum], ensuring that the data order is not disordered during transmission. The receiving end can achieve precise separation through field identifiers.

[0085] S220: Channel transmission of the fused transmission unit: The channel scheduling module will send the completed fused transmission unit to the transmission link of the final channel according to the final channel transmission parameters determined in step S500, such as bandwidth, modulation scheme, and transmission protocol. During transmission, the original error control mechanisms of the system, such as Automatic Repeat Request (ARQ) and Forward Error Correction (FEC), will be used to perform bit error checking and retransmission control on the entire fused transmission unit, ensuring the reliability of fused data transmission and avoiding transmission errors caused by increased data volume.

[0086] S221: Data separation, restoration, and integrity verification at the receiving end: (1) Reception and parsing of the fused transmission unit: After the receiving end (such as an IoT gateway or data processing center) successfully receives the fused transmission unit, it performs data separation according to the following logic: First, identify the tail boundary of the target data: Based on the "data length field" in the header of the target data, calculate the total number of bytes of the target data, and extract the data of the corresponding length from the starting position of the fusion transmission unit as the original target data; The remaining data is the complete data packet: all remaining data is extracted from the position after the tail boundary of the target data, and the header fields of the complete data packet (fusion identifier, data length field, business identifier field, and checksum field) are extracted. Fusion flag verification: Verify whether the fusion flag in the header of the complete data packet is 0xAA. If they are inconsistent, it is determined that the fused data is abnormal and the abnormal handling process is triggered, such as reporting "data fusion abnormal" to the channel scheduling module and requesting retransmission.

[0087] (2) Complete data packet restoration and verification: Data length verification: Based on the "data length field" in the header of the complete data packet, extract the corresponding length of business data body to ensure that there is no data truncation or redundancy; Integrity verification: Using the same CRC16 algorithm as the sender, the check value of the intercepted business data body is calculated and compared with the "check code field" in the header of the complete data packet. If they match, it indicates that the data transmission is complete and has not been tampered with; if they do not match, a retransmission request is triggered. Business data restoration: Remove the header fields and checksum fields of the complete data packet, restore the remaining business data body to the original business data to be transmitted, and distribute it to the corresponding processing module according to the attributes (source, type, priority) corresponding to the business identifier field.

[0088] (3) Results feedback: The receiving end feeds back the data separation and restoration results (success / failure, service identifier, processing time) to the channel scheduling module. The channel scheduling module stores the feedback results in the historical scheduling database as the basis for subsequent channel scheduling strategy optimization and service convergence parameter adjustment.

[0089] After receiving the feedback "Unable to add channel information" in step S217, to ensure the legality, security, and feasibility of the service fusion operation, this embodiment adds a dual-license verification process for service fusion (as steps S218a~S218d) before step S218 (obtaining the service fusion instruction). This process is executed independently by the system's permission verification module to generate a legal and valid service fusion instruction, providing permission support for subsequent data fusion transmission. The specific implementation is as follows: S218a: Trigger service license verification and obtain service license key: (1) Verify trigger conditions: When the permission verification module receives the message "Unable to add channel information" forwarded by the channel scheduling module, along with the core attributes of the service data to be transmitted (service identifier, source terminal ID, service priority), it automatically triggers the first-level permission verification (service permission verification) to ensure the legality of the service to be integrated.

[0090] (2) Key acquisition and preprocessing: The authorization verification module obtains the business license key Kbus from the input end of the business data to be transmitted (i.e., the corresponding wireless IoT terminal) through a preset "key acquisition interface". This key is pre-configured at the factory or dynamically issued by the system backend, and is stored in the terminal's security chip using the AES-128 encryption algorithm. During transmission, it is encrypted using the TLS1.3 protocol to prevent key leakage.

[0091] The authorization verification module preprocesses the received Kbus: it removes redundant fields from the transmission process and restores the original key string according to a preset format (such as Base64 decoding) to ensure that the key format is consistent with the storage format in the preset key database.

[0092] (3) Key database matching logic: The system pre-configures a key database, which is stored encrypted. If an encrypted SQLite version is used, the keys are updated periodically by the system administrator. The storage structure is a relational table of "Business Identifier - Terminal ID - Business License Key - Key Validity Period". The permission verification module performs matching according to the following logic: Based on the "service identifier + terminal ID" of the service data to be transmitted, retrieve the corresponding legitimate key Kbus-legal from the key database; It employs a dual logic of "full character matching + key validity period verification": first, it compares the character consistency between Kbus and Kbus-legal, and then verifies whether the current time is within the validity period of Kbus-legal. The validity period is preset to 90 days and can be adjusted through the system backend. If no corresponding valid key can be found, the characters do not match, or the key has expired, it is determined that "business license verification failed"; if all conditions are met, proceed to the next step.

[0093] S218b: Generate business license instruction: If the business license verification in step S218a passes, the permission verification module automatically generates a business license instruction. The instruction is encapsulated in a standardized JSON format and contains the following core fields:

[0094] If the service license verification fails, the permission verification module generates a "service license failed feedback message" containing the reason for failure (key mismatch / key expired / no corresponding valid key), and sends it to the channel scheduling module. The channel scheduling module adds the service data to be transmitted to the "transmission waiting queue" (the retry mechanism is the same as step S218) to prevent illegal services from triggering the convergence operation.

[0095] S218c: Channel license verification triggered based on service license command: (1) Channel permission triggering logic: The authorization verification module sends the service authorization instruction generated in step S218b to the channel management module, triggering the second-layer authorization verification (channel authorization verification). This verification is triggered serially and is only executed after the service authorization is approved, ensuring the rigor of the verification process.

[0096] (2) Channel operation permission reading and determination: The channel management module stores a preset channel operation license table (a core sub-table of the channel management database). This table is stored according to the dimensions of "channel number - operation type - license status - adapted service priority". The "operation type" includes "data fusion", "separate transmission", "channel expansion", etc., and the "license status" is divided into three categories: "allowed", "prohibited" and "conditionally allowed".

[0097] The channel management module performs verification according to the following logic: Extract the "service priority" and the "final channel number" selected by the channel scheduling module from the service license instruction (determined in step S500); retrieve the record with "channel number = final channel number" and "operation type = data fusion" in the channel operation license table, and extract the corresponding "license status" and "adapted service priority range"; Judgment rules: If the permission status is "allowed" and the service priority is within the adaptation range, it is determined as "channel permission verification passed"; if the permission status is "prohibited", it is directly determined as "channel permission verification failed"; if the permission status is "condition allowed", the current load of the final channel (the transmission load Li calculated in step S201) needs to be verified. Only when Li ≤ 0.7 (preset load threshold) is it determined as "channel permission verification passed" to avoid forced fusion causing transmission congestion when the channel is under high load.

[0098] (3) Generate channel licensing instructions: If the channel license verification passes, the channel management module generates a channel license instruction, also encapsulated in a standardized JSON format. Core fields include: instruction identifier, final channel number, license status, current channel load, adaptation priority range, and signature field (RSA-2048 signature), and sends this instruction back to the authorization verification module. If the channel license verification fails, a "channel license failed feedback message" is generated (reasons: license prohibited / priority mismatch / channel high load), which is forwarded by the authorization verification module to the channel scheduling module, and the pending service data enters the waiting queue.

[0099] S218d: Generate and send service fusion instructions by merging dual licenses. (1) Instruction fusion generation: After receiving the service license instruction in step S218b and the channel license instruction in step S218c, the permission verification module performs instruction fusion verification: confirming that the "service identifier", "terminal ID" and "final channel number" of the two instructions are consistent and that they are both in the "license passed" state, and then generates a service fusion instruction.

[0100] The service fusion instruction consists of a three-layer structure: Instruction header: instruction identifier (UUID), instruction type (fixed to "service fusion"), generation timestamp; License verification information layer: contains core fields of service license instruction and channel license instruction (de-sensitized, signature fields hidden); Data fusion configuration layer: preset header format of fusion data packet (consistent with the complete data packet header of step S219), fusion transmission timeout threshold (default 5s).

[0101] (2) Command sending and storage: The authorization verification module transmits the generated service integration instruction (TLS1.3 protocol) to the channel scheduling module through the "service integration instruction distribution interface". At the same time, it stores the service integration instruction, two original authorization instructions and verification log in the authorization log database (encrypted storage, retained for 90 days for auditing and traceability).

[0102] After receiving the service convergence instruction, the channel scheduling module triggers the subsequent process of step S218 (instruction parsing and data processing to be transmitted), completing the closed-loop connection of "authorization verification - instruction generation - scheduling execution".

[0103] After generating the service fusion instruction based on the aforementioned step S218d, in order to ensure that the data fusion operation minimizes interference with the original service transmission, this embodiment adds a target data precision selection process (as steps S218e~S218h) before step S219 (data packaging and fusion). This process dynamically adapts the selection strategy to the service queue characteristics of the final channel, providing the optimal carrier for subsequent data fusion. The specific implementation is as follows: S218e: Obtain the service queue and data volume of each service in the final channel: (1) Source and definition of business queues: Based on the final channel selected in step S500, denoted as Cfinal, the channel scheduling module extracts all queued service data to be transmitted from the service buffer queue of this channel, forming a service queue Q={Q1, Q2, ..., Qp}, where p is the length of the service queue (i.e. the number of service data items to be transmitted), and Qj represents the j-th service data item in the queue.

[0104] (2) Business data volume statistics and definitions: For each piece of service data Qj in the service queue Q, the channel scheduling module calculates its actual data volume Sj, defined as the total number of bytes after protocol encapsulation (including data header, body, and checksum field), with a calculation precision to 1 byte. During the calculation process, if the service queue Q is empty (p=0), the currently pending service data is directly treated as an independent transmission unit (without fusion operation), and a "Queue empty, no fusion required" log is sent to the system; if p≥1, the subsequent data volume sorting and selection process begins.

[0105] (3) Data storage and preprocessing: The "data identifier-data volume" association information for each piece of business data is stored in a temporary data table, while invalid data (such as data marked as "transmission failed" or "to be retransmitted") is removed to ensure that all business data selected are normal data to be transmitted.

[0106] S218f: Sorting and Basic Filtering of Business Data: The channel scheduling module sorts the actual data volume Sj of all valid service data in the service queue Q in ascending order (from smallest to largest), generating a sorted service data list Qsorted={Qs1, Qs2, ..., Qsp}, where Qs1 corresponds to the service data with the smallest data volume, and Qsp corresponds to the service data with the largest data volume. After sorting, Ss1≤Ss2≤...≤Ssp is satisfied.

[0107] After sorting, record the original queue index, data volume, and transmission sequence (estimated transmission time) of each business data in the sorted list to provide basic data support for the two subsequent selection strategies.

[0108] S218g: Single Target Data Selection Strategy (Strategy 1): (1) Strategy triggering conditions: The system pre-configures a queue length threshold pth (with a value range of 3 to 7, preferably 5 in this embodiment). When the business queue length p≤pth, it is determined to be a "sparse business queue scenario", triggering a single target data selection strategy to avoid selection redundancy caused by group division.

[0109] (2) Select logic and execution: The service data Qs1, which is ranked first in the sorted list Qsorted, is directly selected as the target data, i.e., the "service data with the lowest data volume". The core advantage of this strategy is that the transmission load increment of a single service with the smallest data volume is minimal. After merging the service data to be transmitted, the impact on its transmission latency and success rate can be controlled within a preset threshold (latency increase ≤10ms).

[0110] (3) Boundary scene processing: If the service queue length p=1 (only 1 piece of service data to be transmitted), then this piece of data is directly used as the target data. During fusion, it is transmitted in the structure of "target data + complete data packet" to ensure that the original service transmission is not affected.

[0111] S218h: Group Target Data Selection Strategy (Strategy Two): (1) Strategy triggering conditions: When the length of the business queue p > pth, it is determined to be a "business queue intensive scenario", triggering the group target data selection strategy. The total data volume of the group is used to further reduce the interference of fusion on the overall transmission of the queue.

[0112] (2) Key parameter configuration: Group size n: The preset number of adjacent business data aggregations, with a value range of 2 to 5. In this embodiment, 3 is preferred (balancing the accuracy of the total group data calculation and the computational efficiency). Grouping rules: The data is divided continuously according to the original transmission sequence (queue order) of the business queue, without crossing sequences or repeating. That is, the first to n data items are group 1 G1, the (n+1) to 2n data items are group 2 G2, and so on. If the number of data items remaining at the tail of the queue is less than n (denoted as the number of remaining data items r, 1≤r<n), then the remaining data is divided into a separate last group Gk (k=⌈p / n⌉).

[0113] (3) Calculation and filtering of total group data: For each partitioned group Gm (m=1, 2, ..., k), calculate the total data volume SGm of all business data within the group using the following formula: Sort the total data volume SGm of all groups in ascending order and select the group Gmin with the lowest total data volume; extract the business data with the lowest data volume within group Gmin (i.e., the business data ranked first in the group) as the target data.

[0114] (4) Adaptation to special scenarios: If the total data volume of all groups is equal (SG1=SG2=...=SGk), then the minimum data volume SGm-min within each group is further compared, and the corresponding business data in the group with the smallest SGm-min is selected as the target data to ensure the uniqueness of the selection result.

[0115] Application of target data selection results: After determining the target data through steps S218e~S218h, the channel scheduling module synchronizes the core information of the target data (original queue index, data volume, transmission timing, and data structure) to step S219, which serves as the splicing carrier for the complete data packet of the service data to be transmitted. During the selection process, the switching between the two strategies is automatically triggered by the system based on the service queue length, without manual intervention, ensuring real-time performance and rationality for different queue density scenarios.

[0116] After calculating the second channel contention coefficient based on the aforementioned step S300, in order to ensure that the channel scheduling strategy fully adapts to the timeliness requirements of service data and strengthens the transmission guarantee of high-timeliness services, this embodiment adds a timeliness dimension quantitative evaluation and second channel contention coefficient weight adjustment process (as steps S301~S304) between steps S300 (calculation of the second channel contention coefficient) and S400 (calculation of the comprehensive contention coefficient). This process takes the timeliness requirements of service data content as its core and realizes dynamic and differentiated adjustment of weights. The specific implementation is as follows: S301: Processing timely data based on data content matching: (1) Time-sensitive database configuration: The system pre-configures a timeliness database, which adopts an associative storage structure of "data content type - processing timeliness data" to store the timeliness requirements corresponding to different business data. Specifically: Data content types: Classified by business function and data purpose, including emergency control instructions, real-time monitoring data, historical statistical data, equipment status reporting data, firmware upgrade data, etc., which correspond one-to-one with the results of step S100 "Identify the data content of business data"; Processing timeliness data Ttime: Defined as the longest allowable delay (unit: ms) from the start of business data transmission to the completion of processing at the receiving end, characterizing the timeliness sensitivity of the data; the smaller the Ttime, the higher the timeliness requirement of the data, and if the delay is exceeded, the value of the data will drop sharply (e.g., the timeout of emergency control instructions may lead to equipment failure).

[0117] The following table shows an example of the core storage for a time-sensitive database:

[0118] (2) Data content matching logic: The channel scheduling module extracts the "service data content type" identified in step S100 and uses it as a search keyword to perform exact matching in the timeliness database. If the match is successful, directly obtain the corresponding processing time data Ttime; If a match fails (e.g., a new data type is introduced), the system automatically adapts to the default processing time of the "medium timeliness" level (700ms is preferred in this embodiment) and records the "default timeliness data adaptation" log to provide a basis for subsequent database updates.

[0119] S302: Calculate the degree of timeliness impact: (1) Preset time reference parameters: The system pre-configures a timeliness value Tref, which serves as a benchmark threshold for measuring the degree of timeliness impact. The value is the statistical average of all processed timeliness data (in this embodiment, Tref = 2186ms is calculated based on the above database), and its physical meaning is "the average acceptable latency level of the system".

[0120] (2) Formula for calculating the degree of time-related impact: The timeliness impact value Ktime is used to quantify the timeliness sensitivity of business data. It is negatively correlated with the processing timeliness data Ttime (the smaller Ttime is, the larger Ktime is, and the more significant the timeliness impact). The calculation formula is as follows: Ktime = Tref / Ttime; Value range: Ktime > 0, where Ktime ≥ 2 is high timeliness impact (Ttime ≤ Tref / 2), 1 < Ktime < 2 is medium timeliness impact, and 0 < Ktime ≤ 1 is low timeliness impact; Physical meaning: the larger Ktime is, the more sensitive the data is to transmission delay, and its channel contention capability should be prioritized.

[0121] (3) Verification of calculation results: The channel scheduling module performs a reasonableness check on the calculated Ktime: if Ktime > 10 (extremely high timeliness scenario, such as Ttime = 50ms), it is truncated to 10 (to avoid excessive imbalance in weight adjustment); if Ktime < 0.1 (extremely low timeliness scenario), it is fixed to 0.1 to ensure the stability of the adjustment logic.

[0122] S303: Configure weight adjustment parameters and thresholds: (1) Initial weights and constraints: The initial weight w2 of the second channel contention coefficient preset in step S209 is initially 0.35, and always satisfies w1+w2=1. w1 is the weight of the first channel contention coefficient, which has been adjusted by S209 to ensure the normalization of weight allocation.

[0123] (2) Threshold for the impact level of timeliness: The system presets three timeliness impact thresholds to divide the weight adjustment range: high timeliness impact threshold KH-time=2.0; medium timeliness impact threshold KM-time=1.0; low timeliness impact threshold KL-time=0.1.

[0124] (3) Weight adjustment step size: Configure the timeliness weight adjustment step size Δwtime=0.15 to control the weight adjustment range under different timeliness levels, ensuring that the adjustment process is smooth and the differences are significant.

[0125] S304: Adjusting the weight of the second channel contention coefficient based on the positive correlation of the timeliness impact value: This step employs a positive correlation adjustment logic: the larger the timeliness impact value Ktime, the larger the weight w2 of the second channel contention coefficient, thus giving high-timeliness services a higher weight in the second channel contention coefficient dimension and strengthening their overall competitiveness. The specific segmented quantization adjustment rules are as follows: (1) High time-sensitive impact interval (Ktime≥KH-time): For data with extremely high timeliness requirements (such as emergency control commands), w2 needs to be significantly increased to prioritize channel contention capability: w2 = initial w2 + Δwtime × min((Ktime - KH-time) / KH-time, 1); Adjustment constraint: w2 ≤ 0.5 (to avoid exceeding the weight w1 of the first channel contention coefficient, ensuring priority dominance); Example: Ktime = 2.5, then w2 = 0.35 + 0.15 × (2.5 - 2.0) / 2.0 = 0.3875.

[0126] (2) Time-dependent impact interval (KM-time < Ktime < KH-time): For data with moderate timeliness requirements (such as real-time monitoring data), maintain the initial weight with slight adjustments: w2 = w2_initial + Δwtime × 0.3; after adjustment, w2 = 0.35 + 0.045 = 0.395, balancing timeliness assurance and resource requirements.

[0127] (3) Low timeliness impact range (Ktime≤KM-time): For data with low timeliness requirements (such as historical statistical data), appropriately reduce w2 to reserve weight space for high-priority, high-resource-demand businesses: w2 = w2 initial - Δwtime × min((KM-time - Ktime) / KM-time, 0.5); Adjustment constraint: w2 ≥ 0.2 (to avoid the timeliness dimension being ignored due to excessively low weight); Example: Ktime = 0.5, then w2 = 0.35 - 0.15 × (1.0 - 0.5) / 1.0 = 0.275.

[0128] (4) Application of adjustment results: The adjusted w2 synchronously updates w1=1-w2, and the updated weight combination (w1, w2) is passed to step S400 for weighted calculation of the comprehensive competition coefficient, realizing differentiated scheduling in three dimensions: priority, data volume / resource call volume and timeliness.

[0129] After the service data transmission is completed based on the aforementioned steps S500 (final channel selection and service transmission) or S220 (converged transmission unit transmission), in order to dynamically adapt the adjustment speed of the second channel contention coefficient weight to the actual transmission quality and avoid over-adjustment or response lag, this embodiment adds a transmission quality feedback and weight adjustment speed closed-loop control process (as steps S501~S504). This process takes the transmission quality change trend as the core, reversely adjusts the adjustment speed, and further optimizes the adaptive capability of the scheduling strategy. The specific implementation is as follows: S501: Triggering business feedback tasks and collecting feedback information: (1) Task triggering conditions: When the receiving end (IoT gateway / data processing center) successfully receives the service data (including separately transmitted data and data after fusion and restoration) and completes the integrity verification (such as passing CRC16 verification), it automatically sends a "transmission success confirmation signal" to the channel scheduling module. After receiving the signal, the channel scheduling module immediately triggers the service feedback task and starts the transmission quality data acquisition process.

[0130] (2) Feedback information sources and core fields: Feedback information is generated by the receiving end based on the actual transmission process and transmitted to the channel scheduling module via an encrypted communication link (TLS 1.3 protocol). The core of the feedback includes the following quantifiable fields: Actual transmission delay (tact) (ms): the total time from data transmission from the sending end to the receiving end; Bit error rate (er) (‰): the ratio of the number of erroneous bits to the total number of bits during transmission; Packet loss rate (pr) (‰): the ratio of unsuccessfully received data packets to the total number of transmitted data packets; Transmission channel number (Cused): the final channel number actually used for transmission (consistent with S500); Service identifier and transmission timestamp: corresponding one-to-one with the sending end's data attributes for association and matching.

[0131] (3) Feedback information preprocessing: The channel scheduling module preprocesses the received feedback information: Outlier removal: If a field value exceeds a preset reasonable range (e.g., latency > 10 times the processing time Ttime, bit error rate > 10‰), it is marked as abnormal feedback, and this data will not participate in trend calculation; Data standardization: Each field is transformed according to the "positive transformation" rule (i.e., the larger the value, the better the transmission quality). For example: latency positive transformation value tpos = 1 - min(tact / Ttime, 0.9), where Ttime is taken from S301; bit error rate / packet loss rate positive transformation values ​​epos = 1 - min(er / 10, 0.9), ppos = 1 - min(pr / 10, 0.9).

[0132] S502: Extract transmission quality values ​​and standardize and fuse them: (1) Definition and calculation of transmission quality value: The transmission quality value Q is a weighted fusion value of multi-dimensional transmission indicators, which comprehensively represents the quality level of a single transmission. The calculation formula is as follows: Q=λ1×tpos+λ2×(1-er / 1000)+λ3×(1-pr / 1000); where: λ1, λ2, λ3 are weighting coefficients, with values ​​of 0.4, 0.3, and 0.3 respectively (ensuring λ1+λ2+λ3=1), prioritizing latency indicators; the value range: Q∈[0.1, 1.0], the larger the value, the better the transmission quality.

[0133] (2) Quality value storage and historical data retrieval: The channel scheduling module associates the calculated single transmission quality value Q with the service identifier and channel number and stores it in the transmission quality history database, and manages them in groups according to "service type + channel number". In subsequent calculations, it calls the most recent N valid transmission quality values ​​(N is a preset statistical window, ranging from 5 to 10, preferably 8 in this embodiment) under the same group to form a quality value sequence Q={Q1, Q2, ..., QN}, where QN is the latest quality value.

[0134] S503: Calculate the percentage change trend in transmission quality: (1) Trend calculation logic: The percentage change trend (Rtrend) characterizes the overall direction and magnitude of changes in transmission quality over the most recent N transmissions. A larger value indicates continuously improving transmission quality; a smaller value indicates continuously deteriorating transmission quality or drastic fluctuations. The calculation formula is as follows: Calculate the mean (Qavg) of the historical quality value sequence: ; Calculate the rate of change between the current quality value and the historical average: Rtrend = (QN - Qavg) / Qavg × 100%; Value range: Rtrend ∈ [-50%, 50%], values ​​outside this range are truncated to avoid the influence of extreme values; Physical meaning: Rtrend > 0 indicates that the current quality is better than the historical average, and the larger the value, the better the trend; Rtrend < 0 indicates that the current quality is worse than the historical average, and the smaller the value, the worse the trend.

[0135] (2) Trend smoothing: To avoid misjudging the trend due to a single abnormal quality value, a moving average smoothing is performed on Rtrend: In the formula: Rtrend-(k) represents the percentage change in the current trend and the previous two trends, ensuring the stability of the trend judgment.

[0136] S504: Adjustment speed of the second channel competition coefficient weight based on the percentage negative correlation of the changing trend: (1) Definition and reference parameters for adjusting speed: Definition: The adjustment speed v2 of the second channel contention coefficient weight (unit: / s) is the maximum adjustment range of w2 per unit time (consistent with the S213 adjustment speed definition to maintain system uniformity). Baseline adjustment speed v20: Preset default speed, with a value range of 0.08~0.12 / s, preferably 0.1 / s in this embodiment; Adjustment speed coefficient kv2: Used to quantify the influence of trends on speed, with a value range of 1.2~1.8, preferably 1.5 in this embodiment; Trend threshold: Preset three-level thresholds to divide the adjustment range: Excellent trend threshold RH=10% (transmission quality continues to improve); Stable trend threshold RM=-10% (transmission quality fluctuates slightly); Poor trend threshold RL=-30% (transmission quality continues to deteriorate).

[0137] (2) Negative correlation adjustment rule (core logic: the larger Rtrend-smoothed, the smaller v2; conversely, the smaller the Rtrend-smoothed, the larger v2): The adjustment is performed using a segmented quantization formula, as follows: High-quality trend range (Rtrend-smoothed≥RH): Transmission quality continues to improve, no need for rapid adjustment, slow down the speed to avoid over-optimization: v2=v20 / kv2; Example: v20=0.1 / s, kv2=1.5, then v2≈0.067 / s, the weight is adjusted slowly to maintain the current good state. Stable trend range (RM<Rtrend-smoothed<RH): Transmission quality fluctuates slightly, maintaining a balanced response and stability at the baseline speed: v2=v20; Poor trend range (Rtrend-smoothed≤RL): Transmission quality continues to deteriorate, requiring faster adjustment and optimization: v2=v20×kv2×min((RM-Rtrend-smoothed) / (RM-RL), 1.2) Adjustment constraint: v2≤0.2 / s (avoiding excessive speed leading to weight oscillation); Example: Rtrend-smoothed=-20%, then v2=0.1×1.5×((-10%)-(-20%)) / ((-10%)-(-30%))=0.1125 / s, accelerating adjustment to improve transmission quality. Fluctuation trend range (RL<Rtrend-smoothed≤RM): Transmission quality fluctuates drastically. Moderately slow down the speed to avoid frequent adjustments: v2=v20×0.8; Example: v2=0.08 / s, to reduce the impact of weight fluctuations on transmission stability.

[0138] (3) Application of speed adjustment: The calculated v2 directly affects the second channel contention coefficient weight adjustment process in the subsequent step S304: when w2 needs to be updated, the actual weight smoothly transitions from the current value w2_curr to the target value w2_new at the rate of v2, and the transition time ttrans2=|w2_new-w2_curr| / v2, realizing the closed-loop adaptation of "transmission quality-adjustment speed-weight update".

Claims

1. A service-based adaptive channel contention and scheduling method for wireless Internet of Things (IoT) terminals, characterized in that, Includes the following steps: Acquire business data, match the corresponding business priority from the preset priority database based on the business data, identify the data content of the business data, and match the corresponding processing data volume and resource call volume from the preset processing database based on the data content; Based on service priority, a first channel contention coefficient is matched. Based on the first channel contention coefficient, the priority of the transmission channel is matched to the service data. The priority of the transmission channel corresponds to the first channel contention coefficient. Based on the priority of the transmission channel, the corresponding transmission channel is marked as a candidate channel. All service data in the candidate channels are obtained, and the amount of computational data and resource call volume corresponding to each service data are obtained. The average data volume is calculated based on the average value of the calculated data volume of all business data, and the average resource call volume is calculated based on the average value of the calculated data volume. The data ratio is obtained based on the ratio of the calculated data volume to the average data volume, and the resource ratio is obtained based on the ratio of the resource call volume to the average call volume. The second channel contention coefficient is calculated based on the data ratio and the resource ratio. The comprehensive competition coefficient is calculated based on the first channel competition coefficient and the second channel competition coefficient, wherein the weight of the first channel competition coefficient is greater than the weight of the second channel competition coefficient. Based on the comprehensive competition coefficient, each transmission channel in the candidate channels is sorted, and the transmission channel with the highest ranking is selected as the final channel, through which the service data is sent. If the comprehensive competition coefficient is the same in multiple transmission channels, the transmission frequency of the service data task in each transmission channel is calculated, and the transmission channel with a transmission frequency lower than the preset frequency reference value is selected as the final channel.

2. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 1, characterized in that, The step of marking the corresponding transmission channel as a candidate channel according to the priority of the transmission channel also includes the following steps: Obtain the transmission load in the transmission channel corresponding to each priority, calculate the ratio of transmission load to total load as the transmission occupancy rate, and calculate the transmission idle rate = 1 - transmission occupancy rate; If the number of candidate channels is greater than the preset reference number, the candidate channels are sorted according to the transmission idle rate, and the last set number of candidate channels are marked. The average idle rate is calculated by taking the average idle rate of the remaining candidate channels, and the set quantity is adjusted according to the positive correlation of the average idle rate.

3. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 2, characterized in that, The method also includes the following steps: Calculate the uniformity of the transmission idle rate distribution of the candidate channels, and calculate the uniformity comparison value based on the uniformity of the distribution and the preset reference uniformity. The idle rate is calculated based on the average idle rate and the preset reference idle rate. The channel condition comparison value is calculated based on the uniform comparison value and the idle comparison value. The weight of the first channel contention coefficient is adjusted according to the negative correlation of the channel condition comparison value.

4. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 3, characterized in that, The method also includes the following steps: The final channel corresponding to the service data with the same priority is the historical channel. The number of channel numbers of the historical channels is the channel quantity. The ratio of the channel quantity to the total number of all transmission channels is the median value of the channel quantity. Business data with the same source, priority, and content attributes are considered to be of the same source. The number of times the same source business data calls the transmission channel is the total number of transmissions. The number of times the same source business data changes the final channel is the number of changes. The ratio of the number of changes to the total number of transmissions is the median value of the channel changes. The intermediate value of channel call is calculated based on the median value of the number of channels and the median value of channel transformation; The adjustment speed of the weight of the first channel contention coefficient is controlled by the positive correlation between the channel call median value and the control.

5. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 4, characterized in that, The method also includes the following steps: If the intermediate value of the channel call is greater than the preset maximum value of the channel call, a new channel request will be issued; Based on the request to add a channel, query the channel connection port; If an expandable channel connection port exists, a new transmission channel is requested to be established based on the channel connection port; otherwise, it is returned that no new channel information can be added.

6. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 5, characterized in that, The method also includes the following steps: Since it is impossible to add new channel information, service convergence instructions are obtained in real time. If a service fusion instruction is obtained, the service data to be transmitted corresponding to the service fusion instruction is packaged into a complete data packet, and the service data to be transmitted in the final channel of the corresponding service data to be transmitted is taken as the target data. The service data to be transmitted corresponding to the service fusion instruction is then merged at the end of the target data. After transmission is complete, the target data and the complete data packet are separated from the received business data, and the complete data packet is restored to the business data.

7. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 6, characterized in that, The method also includes the following steps: Service convergence instructions include service licensing instructions and channel licensing instructions; First, trigger the business license information, then obtain the business license key from the input terminal based on the business license information. If the business license key matches the preset key database, then generate a business license instruction. Based on the generated service license instruction, the channel license information is triggered. Based on the channel license information, the channel operation license is read from the preset line. If the content of the channel operation license is a convergence license, then a channel license instruction is generated. Service convergence instructions are generated and sent based on service license instructions and channel license instructions.

8. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 7, characterized in that, The method also includes the following steps: The queue that acquires the existing service data in the final channel is called the service queue; Get the data volume of business data in the business queue and sort the data volume; Use the business data with the lowest data volume as the target data; Alternatively, take n adjacent business data as a business group, calculate the sum of the data volume in the business group, and take the business data with the lowest data volume in the business group with the lowest sum as the target data.

9. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 1, characterized in that, The method also includes the following steps: Based on the data content, the corresponding processing time data is matched from the preset time database; The impact of timeliness is calculated based on the processing timeliness data and the preset timeliness correspondence value; The weight of the second channel competition coefficient is adjusted based on the positive correlation between the timeliness impact value and the timeliness impact value.

10. The service-based adaptive channel contention and scheduling method for wireless IoT terminals according to claim 9, characterized in that, The method also includes the following steps: A business feedback task is triggered after successful business data transmission. Based on the business feedback task, obtain feedback information and extract transmission quality values ​​from the feedback information; The percentage change trend is calculated based on multiple transmission quality values, and the adjustment speed of the weight of the second channel competition coefficient is controlled according to the negative correlation of the percentage change trend.

Images