A cloud-computing-based intelligent resource control method for wearable devices

Abstract

This invention discloses a cloud-based intelligent resource control method for wearable devices, relating to the field of wearable device resource scheduling technology. The method includes obtaining a data packet, the data packet comprising multi-dimensional dynamic attribute encoding and real-time data; obtaining a priority through the multi-dimensional dynamic attribute encoding; selecting and allocating a transmission time window for the data packet based on the priority; sending the data packet within the transmission time window; obtaining service quality requirements based on the data packet; initiating a closed-loop confirmation mechanism based on the service quality requirements; receiving the data packet through the cloud, obtaining real-time data, performing context recognition and matching on the real-time data, obtaining the matching result, and issuing resource control commands to the wearable device based on the matching result. This invention, through the cloud's context recognition capabilities, issues resource control commands to achieve dynamic and optimized allocation of local resources in the wearable device, improving system energy efficiency, data transmission reliability, and user experience.

Description

Technical Field

[0001] This invention relates to the field of wearable device resource scheduling technology, and in particular to a cloud computing-based intelligent resource control method for wearable devices. Background Technology

[0002] With the increasing popularity and complexity of smart wearable devices, the challenge lies in how to balance real-time performance, accuracy, and energy consumption when resources are limited, such as battery capacity, computing power, and communication bandwidth, to perform data collection, transmission, and processing tasks.

[0003] Currently, Chinese patent application number CN202110827557.2 discloses a data transmission method and a wearable device. This method involves a processing module that can generate data for display content and then send data to the display module at any time. Upon receiving the data, the display module stores it in a storage unit. The display module uses the rising edge of a control signal as a trigger condition and performs self-refresh according to the frequency of the control signal. Furthermore, the frequency at which the processing module sends data is consistent with or similar to the frequency at which the display module performs self-refresh. This method prevents tearing of the displayed content while eliminating the need for the processing module to wake up on every rising edge. It also reduces the number of times the processing module wakes up when not sending data, thereby reducing power consumption.

[0004] The aforementioned technologies struggle to manage and process all data sources, are unable to dynamically adjust strategies based on the real-time status of smart wearable devices, network conditions, and the importance of the data content itself, lack context awareness and business coupling, and are unable to cope with network and complex environment challenges. Summary of the Invention

[0005] The technical problem solved by this invention is that existing technologies are difficult to manage and process all data sources, cannot dynamically adjust strategies based on the real-time status of smart wearable devices, network conditions, and the importance of the data content itself, lack context awareness and business coupling, and cannot cope with network and complex environments.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a cloud computing-based intelligent resource control method for wearable devices, comprising the following steps: Step S1: Obtain a data packet by monitoring sensor and application data from the wearable device. The data packet includes multidimensional dynamic attribute encoding and real-time data. Step S2: Obtain the priority through the multidimensional dynamic attribute encoding, and select and allocate a transmission time window for the data packet corresponding to the multidimensional dynamic attribute encoding from the preset transmission strategy according to the priority. Step S3: Send the data packet within the allocated transmission time window; obtain the service quality requirements based on the data packet; and initiate the closed-loop confirmation mechanism based on the service quality requirements. Step S4: Receive the data packet through the cloud, obtain real-time data based on the data packet, perform context recognition and matching on the real-time data, obtain the matching result, and issue resource control instructions to the wearable device based on the matching result to complete the control closed loop.

[0007] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, step S1 includes the following sub-steps: Step S101, the real-time data includes physiological health data, sports environment data, user interaction data, and application-layer specific data; Step S102: Based on the real-time data, obtain context information, and generate the multidimensional dynamic attribute code through a preset rule table based on the context information. The context information includes task identifier and content status, and the multidimensional dynamic attribute code includes task identifier, priority, data load size, time sensitivity, and service quality requirements. Step S103, the task identifier is used to identify the data source; The priority is assigned according to the task identifier and real-time data through the rule table, and the priority includes the highest level, the second highest level, and the normal level; The time sensitivity and quality of service requirements are defined based on the priority and task identifier.

[0008] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, the preset rule table specifically includes: Step S104: Establish a mapping relationship between the context information and the priority, time sensitivity and service quality requirements, and match the context information with the rule table to obtain the first matching result; Step S105: Based on the first matching result, assign corresponding priority, time sensitivity and quality of service requirements to the real-time data, and construct the multi-dimensional dynamic attribute code based on the priority, time sensitivity and quality of service requirements.

[0009] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, the preset transmission strategy specifically includes: Step S201, the transmission strategy includes a preemptive immediate window strategy, a periodic synchronization window strategy, and an idle time window strategy; Step S202, the preemptive immediate window strategy is to interrupt the transmission of the current low-priority data packet when the priority is the highest, and allocate a transmission time window for the data packet with the highest priority. The periodic synchronization window strategy is as follows: when the priority is the second highest, the corresponding multidimensional dynamic attribute code is obtained according to the data packet; the time sensitivity is obtained according to the multidimensional dynamic attribute code; and the data packet is placed in the queue waiting for the next periodic synchronization window according to the time sensitivity. The idle time window policy is to place the data packet into the idle time window queue when the priority is normal. The idle time window queue is a queue that is only opened when the device is in an idle state.

[0010] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, the duration of the transmission time window is calculated based on the data load size of the data packet and the estimated data packet transmission rate. When allocating the transmission time window, the device resource status vector is also considered. The device resource status vector reflects the current operating status of the wearable device in real time and includes the current battery level, current processor load, and current network signal strength of the wearable device.

[0011] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, step S3 includes the following sub-steps: Step S301: Send the data packet according to the transmission time window; obtain the multidimensional dynamic attribute code according to the data packet; obtain the service quality requirements according to the multidimensional dynamic attribute code; the service quality requirements include reliable transmission and unreliable transmission. Step S302: When the quality of service requirement is reliable transmission, a closed-loop confirmation mechanism is initiated. Step S303: When the quality of service requirement is unreliable transmission, then transmission is performed.

[0012] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, the closed-loop confirmation mechanism specifically includes: Step S304: After the data packet is sent, a timer is started. The duration of the timer is set by the time sensitivity value in the multidimensional dynamic attribute encoding. Step S305: According to the duration, the sender waits and listens for an acknowledgment signal from the receiver; Step S306: If an acknowledgment signal is received before the timer expires, the transmission is considered successful. If the timer times out without receiving an acknowledgment signal, the transmission is considered to have failed. Step S307: When a transmission failure is determined, the multidimensional dynamic attribute encoding of the data packet is modified, the priority is increased by one level, a new multidimensional dynamic attribute encoding is obtained, the modified data packet is obtained according to the new multidimensional dynamic attribute encoding, and the modified data packet is resubmitted to the queue as the front end.

[0013] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, step S4 includes the following sub-steps: Step S401: Based on the data packet, obtain real-time data, and obtain historical behavior data and external environment data through the cloud. The historical behavior data includes the user's average daily steps, common exercise time periods, sleep habits and usual location. The external environment data includes the current time, weather conditions and geographical location information. Step S402: The historical behavior data, external environment data, and real-time data are matched using a predefined context recognition rule base to obtain matching results; Step S403: Based on the matching result, obtain the specific context in which the user is currently located.

[0014] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, step S4 further includes obtaining a resource control instruction according to the specific situation. The resource control instruction is used to adjust the execution parameters of the local tasks of the wearable device. The execution parameters include GPS sampling rate, heart rate sensor sampling frequency, and screen brightness.

[0015] As a preferred embodiment of the intelligent resource control method for wearable devices based on cloud computing described in this invention, the rule table and the context recognition rule base both need to be updated regularly and on demand through the cloud to obtain new rule tables and context recognition rule bases in order to adapt to changes in user behavior and device firmware upgrades.

[0016] The beneficial effects of this invention are as follows: By generating dynamic attribute codes for each data packet, including dimensions such as priority, time sensitivity, and quality of service requirements, fine-grained classification and management of heterogeneous data streams can be achieved. Combined with preset, hierarchical transmission strategies, valuable wireless transmission time windows can be dynamically allocated based on the real-time business value of the data and the current state of the device. This mechanism ensures the timely and reliable transmission of high-urgency, high-value data, while delaying the batch transmission of non-urgent data until the network is idle or the device is charging, thus optimizing the utilization efficiency of network bandwidth and reducing network conflicts and energy waste caused by blind transmission. By introducing a closed-loop confirmation mechanism bound to data service quality requirements, for critical data requiring reliable transmission, an adaptive timer is started after transmission and confirmation is awaited. If transmission fails, the priority of the data packet is increased, giving it priority processing in the retransmission queue, ensuring that critical business data can still be transmitted with maximum effort even in harsh network environments. The system's ability to deliver robust solutions enhances its responsiveness and reliability in the face of critical events. By integrating real-time data uploaded from devices, long-term historical user behavior data, and external environmental data from the cloud, and through multi-source information fusion and matching via a contextual recognition rule base, it can more accurately determine the user's current context. Based on this precise contextual judgment, cloud-based resource control commands avoid the bias and misoperation inherent in local device control based on single sensor signals. This ensures that device resource consumption is highly aligned with the user's actual needs. Both the rule tables and the contextual recognition rule base are deployed in the cloud and support dynamic updates. As user habits change, new applications are installed, or device firmware is upgraded, the cloud can periodically or on demand update these rules and synchronize the updates to the device. This allows the entire system's decision-making logic to continuously learn, optimize, and adapt, ensuring the long-term effectiveness of control strategies and personalized service levels, thereby enhancing user stickiness and product lifecycle value. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the steps of a cloud-based intelligent resource control method for wearable devices, as provided in one embodiment of the present invention. Detailed Implementation

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] Example, refer to Figure 1 This paper provides a cloud-based intelligent resource control method for wearable devices, comprising the following steps: Step S1: Obtain data packets by monitoring sensor and application data from the wearable device. The data packets include multidimensional dynamic attribute encoding and real-time data. Step S2: Obtain priority through multidimensional dynamic attribute encoding; select and allocate transmission time windows for data packets corresponding to multidimensional dynamic attribute encoding from the preset transmission strategy according to the priority. Step S3: Send data packets within the allocated transmission time window; obtain service quality requirements based on data packets; and initiate a closed-loop confirmation mechanism based on service quality requirements. Step S4: Receive data packets from the cloud, obtain real-time data based on the data packets, perform context recognition and matching on the real-time data, obtain the matching results, and issue resource control commands to the wearable device based on the matching results to complete the control closed loop.

[0020] Step S1: Obtain data packets by monitoring sensor and application data from the wearable device. The data packets include multidimensional dynamic attribute encoding and real-time data. Starting with data perception and intelligent characterization, by deploying persistent data monitoring and encapsulation services on wearable devices, various raw and heterogeneous real-time data generated by the devices are transformed into intelligent data packets containing standardized, self-describing metadata, i.e., multi-dimensional dynamic attribute encoding, based on business semantics and contextual information. This provides a core basis for subsequent differentiated transmission scheduling and cloud-based intelligent decision-making.

[0021] Step S101: Real-time data includes physiological health data, exercise environment data, user interaction data, and application-specific data; By using a data monitoring service, a comprehensive understanding of device data sources can be achieved. In the operating system of wearable devices such as smartwatches, a resident data monitoring and management service with system-level permissions is deployed. It monitors the output of all hardware sensors through the hardware abstraction layer interface of the operating system and monitors the data streams generated by various software applications through application programming interfaces or inter-process communication mechanisms.

[0022] Physiological health data comes from biomedical sensors used to monitor the user's vital signs. For example, heart rate and heart rate variability waveform data are continuously collected by photoplethysmography (PPG) sensors, electrocardiogram (ECG) signals are collected by ECG sensors, blood oxygen percentage values ​​are collected by blood oxygen saturation sensors, and body surface temperature data are collected by body temperature sensors.

[0023] The motion environment data comes from motion and environmental sensing sensors, which are used to capture user activities and the surrounding physical state. For example, the raw data of triaxial acceleration and angular velocity output by accelerometers and gyroscopes are used for activity recognition and step counting; latitude, longitude, speed and altitude information output by the GPS module; illuminance values ​​output by the ambient light sensor; and barometric pressure data output by the barometer.

[0024] User interaction data comes from user-initiated actions on the device, such as touchscreen clicks and swipes, physical button presses, voice assistant activation commands and voice content, and screen brightness switching events.

[0025] Application-layer specific data comes from business information pushed by third-party applications or system services running on the device. For example, notification message titles and summaries from contacts, SMS, and social applications; schedule reminders from calendar applications; playback status from music players; and route guidance from navigation applications.

[0026] After capturing data from any of the above sources, the monitoring service treats the data as a batch of real-time data to be processed, preparing it for context analysis and feature encoding. This ensures that the system can cover all key information dimensions produced by wearable devices, providing a data foundation for building a complete user status profile.

[0027] Step S102: Obtain context information based on real-time data, and generate multidimensional dynamic attribute codes based on the context information through a preset rule table. The context information includes task identifier and content status, and the multidimensional dynamic attribute codes include task identifier, priority, data load size, time sensitivity and service quality requirements. The raw real-time data undergoes semantic parsing and standardized encoding. After capturing real-time data, the data monitoring service extracts contextual information. This contextual information is a preliminary description for understanding the meaning of the data's business logic, including task identifiers and content status. The task identifier is a unique or categorized string encoding that directly indicates the source of the data or the task that generated it. It is determined directly based on the channel through which the data is being monitored, such as HEART_RATE_ALERT (heart rate alarm), GPS_TRACKING (GPS tracking), and MESSAGE_NOTIFICATION (message notification). The content status is a concise description of the specific value or event represented by the current batch of data. For example, for heart rate data, the content status might be VALUE:180 (heart rate value 180 beats / min) or EVENT:TACHYCARDIA (event: tachycardia). For accelerometer data, after processing with a simple local algorithm, the content status might be EVENT:FALL_DETECTED (event: fall detection) or ACTIVITY:RUNNING (status: running).

[0028] The system generates codes by querying a preset rule table. The device has a preset rule table stored locally, which defines the mapping logic from context information to a set of transmission and control attributes. The system takes the extracted context information as input, queries this rule table, and outputs and combines the various fields of a multi-dimensional dynamic attribute code. The task identifier is directly inherited from the context information; priority is dynamically assigned based on the rule table's matching results with the context information, used to identify the importance level of data in the system. The rule table typically defines several levels, such as the highest level (e.g., emergency life alerts and fatal system errors), the second highest level (e.g., navigation data and important interactive notifications), and the ordinary level (e.g., regular logs and historical statistics); data load size is an objective numerical field, representing the number of bytes of the original real-time data to be transmitted, calculated directly by the system; time sensitivity defines the maximum tolerable end-to-end delay from data generation to successful processing, related to priority, but precisely defined by the rule table based on the specific business scenario. For example, the time sensitivity of the highest-level alarm may be less than 1 second; the quality of service requirement defines the reliability requirements for data transmission, which is divided into reliable transmission and unreliable transmission. It is determined by the rule table based on the task identifier and content status. For example, the rule table may contain a logic like this: IF(Task_ID==“FALL_DETECTION_ALERT”)THENPriority=highest level, Time_Sensitivity=extremely sensitive (500ms), QoS=reliable transmission. When a fall event is detected, the system will automatically generate the corresponding code.

[0029] Step S103: The task identifier is used to identify the data source; Priorities are assigned based on task identifiers and real-time data through a rule table. Priorities include the highest, second-highest, and normal levels. Time sensitivity and service quality requirements are defined based on priority and task identifiers.

[0030] Clarify the generation logic and function of each encoding field, and further clarify the key fields in step S102. The core function of the task identifier is to uniquely or classify the data source in the entire edge-cloud system. The cloud server relies on this identifier to determine which algorithm or model to use to process the received data. Priority allocation is based entirely on a pre-defined rule table. The rule table takes the specific task identifier and the content status derived from the real-time data as joint inputs, and outputs the corresponding priority level by matching the internal mapping relationship. This allows the same data source to be assigned different priorities in different states. The generation of time sensitivity and service quality requirements is defined based on priority and task identifier. The rule table allows for fine-grained configuration. For example, for data belonging to the second-highest priority, a software upgrade package may require reliable transmission but has low time sensitivity, while a real-time voice data packet may require high time sensitivity but can accept unreliable transmission. This design achieves the optimal match between business needs and transmission resources.

[0031] Step S104: Establish a mapping relationship between context information and priority, time sensitivity and service quality requirements, and match the context information with the rule table to obtain the first matching result; The pre-defined rule table is loaded into memory during system initialization. Essentially, it is a set of mapping relationships from context information to control attributes. The matching process can be an efficient hash lookup or a series of if-then conditional statements. When new context information is generated, the system compares the context information with the entries in the rule table and outputs the first matching result, which is a set of assignments that determine priority, time sensitivity, and service quality requirements. This method standardizes and modularizes complex business logic judgments, making policy behavior clear and controllable.

[0032] Step S105: Based on the first matching result, assign corresponding priority, time sensitivity and service quality requirements to the real-time data, and construct a multi-dimensional dynamic attribute code based on the priority, time sensitivity and service quality requirements.

[0033] Based on the first matching result, the assigned attribute values, objective data load size, and inherent task identifier are written into a standard format data structure header to form the final multidimensional dynamic attribute code. The multidimensional dynamic attribute code is used as the metadata header and concatenated with the original real-time data load to form a complete, self-describing data packet. Thus, the original data becomes a standard transmission unit carrying its own importance, urgency, and reliability requirements.

[0034] By monitoring and classifying all source data, a unified data ingestion framework was established. Through dynamic encoding based on the rule table, the business semantics of the data were transformed into machine-quantifiable decision parameters, enabling subsequent steps to be efficiently scheduled without parsing complex content, greatly improving real-time processing. Business rules were centralized in an updatable rule table, giving the device's data labeling strategy flexibility and evolvability.

[0035] Step S2: Obtain priority through multidimensional dynamic attribute encoding, and select and allocate transmission time windows for data packets corresponding to multidimensional dynamic attribute encoding from the preset transmission strategy according to the priority.

[0036] Based on the priority of the data packet and combined with the device's real-time resource status vector, the most suitable transmission strategy is selected from the hierarchical transmission strategy library, and a specific transmission time window is calculated and allocated. This ensures that high-value data occupies the wireless channel preferentially and efficiently under resource-constrained conditions.

[0037] Step S201: The transmission strategies include preemptive immediate window strategy, periodic synchronization window strategy, and idle time window strategy. A hierarchical transmission strategy library is established to cope with different service requirements. The transmission scheduler maintains a set containing three core strategies, each corresponding to data with different priorities. The preemptive immediate window strategy is designed specifically for the highest priority data. When a data packet arrives, if the channel is occupied by low-priority data transmission, the scheduler has the right to interrupt the current transmission or immediately insert it after it ends, opening an exclusive, immediately starting transmission window for the highest priority data. This strategy ensures zero-wait reporting of emergency events such as cardiac arrest alarms. The periodic synchronization window strategy is designed specifically for the next highest priority data. The system presets periodic time windows, for example, every 2... The system opens a 100-millisecond window every second. After a secondary high-priority data packet is generated, it is placed in a dedicated waiting queue. When the next periodic window opens, the scheduler sorts the packets in order and combines time sensitivity with secondary sorting, and retrieves the data packets from the queue for transmission. This strategy is suitable for continuous services that require timeliness but are not urgent, such as navigation data synchronization. The idle time window strategy is designed specifically for ordinary-level data. The system defines the conditions for determining the idle state, such as screen timeout, device charging, and no high-priority tasks. The idle time window is only opened when the device is idle, and ordinary-level data, such as historical logs and cached data, is retrieved in batches from the idle queue for transmission. This strategy minimizes the interference of low-priority transmission on user experience and device battery life.

[0038] Step S202, the preemptive immediate window strategy is to interrupt the transmission of the current low-priority data packet when the priority is the highest, and allocate a transmission time window for the data packet with the highest priority. The periodic synchronization window strategy is as follows: when the priority is the second highest, the corresponding multidimensional dynamic attribute code is obtained based on the data packet; the time sensitivity is obtained based on the multidimensional dynamic attribute code; and the data packet is placed in the queue waiting for the next periodic synchronization window based on the time sensitivity. The idle time window policy places data packets into the idle time window queue when the priority is normal. The idle time window queue is a queue that is only opened when the device is idle.

[0039] Priority fields are obtained by parsing the multidimensional dynamic attribute encoding of data packets. Corresponding strategies are triggered based on priority fields. When the priority is the highest, a preemptive immediate window strategy is triggered unconditionally. When the priority is the second highest, a periodic synchronization window strategy is triggered, and data packets are placed in the corresponding queue, with the order in the queue determined by the time sensitivity field. When the priority is normal, an idle time window strategy is triggered, and data packets enter the idle queue to wait for the device to enter an idle state. The clear mapping relationship ensures the stability and predictability of scheduling decisions.

[0040] The duration of the transmission time window is calculated based on the data payload size of the data packets and the estimated data packet transmission rate; When allocating transmission time windows, the device resource status vector is also considered. The device resource status vector reflects the current operating status of the wearable device in real time. The device resource status vector includes the current battery level, current processor load, and current network signal strength of the wearable device.

[0041] After determining the strategy to use, the specific duration of each transmission window must be decided, and a resource compliance check must be performed before final allocation. The window duration is calculated based on the data payload size of the data packet (from the encoding) and the current estimated data packet transmission rate (from network link layer feedback), such as the PHY rate calculation for Wi-Fi. The formula can be simplified to Window Duration = Data Payload Size / Estimated Transmission Rate + Fixed Protocol Overhead Margin. For example, a 10KB alarm data packet at a rate of 1Mbps has a theoretical transmission time of about 80ms, and the window can be set to 100ms. This avoids wasting channel resources due to an excessively long window or causing transmission interruption due to an excessively short window. Combined with the device resource status vector, before the final allocation of the window, the scheduler must consult the device resource status vector. This is an internally updated data structure that reflects the device's own operating status, mainly including the current battery level, current processor load, and current network signal strength, such as RSRP for cellular networks or RSSI for Wi-Fi.

[0042] The demand window calculated based on data attributes needs to be verified against the current supply capacity of the equipment. For example, even if a top-level data packet requires an immediate window, if the current battery level is below 2%, the system may decide to send only a minimal alert instead of a full data packet. If the network signal is extremely weak and the estimated rate is too low, the system may postpone the transmission of non-urgent data or choose a more robust but slower encoding mode for urgent data.

[0043] By using dynamic window calculation, precise allocation of network resources is achieved. By introducing device resource state vectors, transmission scheduling is no longer simply data-driven, but resource-aware. This prevents inefficient or high-energy-consuming transmissions when device resources are nearing depletion, achieving an optimal balance between energy efficiency, performance, and reliability overall.

[0044] Step S3: Send data packets within the allocated transmission time window, obtain service quality requirements based on the data packets, and initiate a closed-loop confirmation mechanism based on the service quality requirements.

[0045] After the data packet is allocated to the window, a decision is made on whether to activate a reliable end-to-end delivery guarantee mechanism based on the quality of service requirements. This is a crucial step in ensuring that critical data is delivered.

[0046] Step S301: Send data packets according to the transmission time window; obtain multi-dimensional dynamic attribute codes according to the data packets; obtain service quality requirements according to the multi-dimensional dynamic attribute codes; service quality requirements include reliable transmission and unreliable transmission. Step S302: When the quality of service requirement is reliable transmission, the closed-loop confirmation mechanism is initiated. Step S303: When the quality of service requirement is unreliable transmission, then transmission is performed.

[0047] Within the specific transmission time window allocated in step S2, the device's network protocol stack executes the data packet sending operation. Simultaneously, the system reads the Quality of Service (QoS) requirement field in the data packet encoding to implement differentiated transmission guarantees based on QoS. If the QoS requirement is reliable transmission, it indicates that the data must be delivered to the cloud, such as health alarms and control command confirmations. After transmission is completed, the system initiates a closed-loop confirmation mechanism. If the QoS requirement is unreliable transmission, it indicates that the data can tolerate a certain degree of loss, such as continuous motion sensor sampling streams and real-time voice frames. After transmission is completed, the system considers the task complete, releases resources directly without waiting or confirmation.

[0048] By differentiating transmission assurance levels based on the business nature of the data, the extra ACK waiting and retransmission overhead caused by using a one-size-fits-all reliable transmission is avoided. While ensuring the reliability of critical data, the transmission efficiency of non-critical data and the overall network utilization are further improved.

[0049] Step S304: After the data packet is sent, start the timer. The duration of the timer is set by the time sensitivity value in the multidimensional dynamic attribute encoding. Step S305: Depending on the duration, the sender waits and listens for an acknowledgment signal from the receiver; Step S306: If an acknowledgment signal is received before the timer expires, the transmission is considered successful. If the timer times out without receiving an acknowledgment signal, the transmission is considered to have failed. Step S307: When a transmission failure is determined, the multidimensional dynamic attribute encoding of the data packet is modified, the priority is increased by one level, a new multidimensional dynamic attribute encoding is obtained, the modified data packet is obtained according to the new multidimensional dynamic attribute encoding, and the modified data packet is resubmitted to the queue as the front end.

[0050] After the closed-loop confirmation mechanism is initiated for reliable data transmission, the following process is executed: After the data packet is sent, a timer is started immediately. The duration is not a fixed value, but is dynamically set according to the time sensitivity value in the data packet encoding. For example, if the time sensitivity is extremely sensitive (<1 second), the timer can be set to 300ms; if it is sensitive (<5 seconds), it can be set to 2 seconds. During the timer's operation, the device continuously listens for the acknowledgment (ACK) message returned from the cloud. If an ACK is received before the timeout, the transmission is considered successful and the process ends. If no ACK is received after the timer expires, the transmission is considered to have failed. After the transmission fails, the system does not simply retry with the original attributes, but modifies the multi-dimensional dynamic attribute encoding of the original data packet. Specifically, its priority is increased by one level, for example, from "second-highest" to "highest". A modified data packet is generated with a new encoding header and resubmitted to the front of the transmission queue. Since the priority has been increased, it will be immediately rescheduled for transmission in step S2 with a higher priority strategy, such as preemptive immediate window.

[0051] By deeply integrating retransmission logic with business value, transmission failure may indicate a deteriorating network environment or more urgent data. By increasing its priority, giving it higher scheduling weight and more transmission opportunities in harsh environments, the reliability of system transmission is ensured. The system intelligently tilts towards the most needed data, significantly improving the final delivery probability of critical business data in complex wireless environments and enhancing system robustness.

[0052] Step S4: Receive data packets from the cloud, obtain real-time data based on the data packets, perform context recognition and matching on the real-time data, obtain the matching results, and issue resource control commands to the wearable device based on the matching results to complete the control closed loop.

[0053] Leveraging the powerful computing and storage capabilities of the cloud, the system integrates real-time device data, long-term user behavior data, and external environmental information. Through in-depth analysis using a context recognition rule base, it accurately determines the user's current state and generates personalized device resource control commands accordingly, completing a full closed loop from perception to optimized control.

[0054] Step S401: Based on the data packet, obtain real-time data and historical behavior data and external environment data through the cloud. The historical behavior data includes the user's average daily steps, common exercise time periods, sleep habits and usual location. The external environment data includes the current time, weather conditions and geographical location information. The cloud server receives and parses data packets from the device, extracting real-time data. Simultaneously, the cloud retrieves the user's historical behavior data from the associated user database. This data is derived through statistical analysis of the user's long-term usage data, such as the user's average daily steps, common exercise times (e.g., 7-9 PM), regular sleep habits (e.g., 11 PM-7 AM), and permanent geographical location (e.g., home and company coordinates). External environmental data is obtained by calling third-party service APIs, such as obtaining the current time, weather conditions (sunny, rainy, and temperature) along the route through the National Meteorological Bureau API. GPS coordinates are converted into geographical location information through geocoding services, such as in Olympic Park. This aggregation provides a comprehensive data foundation for accurate context recognition.

[0055] Step S402: Match historical behavior data, external environment data, and real-time data using a predefined context recognition rule base to obtain matching results; Step S403: Based on the matching results, obtain the specific context in which the user is currently located.

[0056] A context recognition engine runs in the cloud. At its core is a predefined context recognition rule base, which contains a series of complex IF-THEN rules and machine learning models. The engine takes aggregated real-time data, historical behavior data, and external environment data as input and matches them with the rule base. For example, a rule is "IF (time is 23:00-07:00) AND (historical behavior: usually sleep during this time) AND (real-time data: very low exercise, stable heart rate) AND (ambient light: dark) AND (geographic location: at home) THEN context = 'deep sleep'". After a successful match, the engine outputs a specific, high-level semantic label, i.e., the specific context, such as deep sleep at night, outdoor running at noon, commuting on the subway, prolonged sitting at the office, and abnormal health conditions such as atrial fibrillation.

[0057] By cross-validating real-time perception, long-term patterns, and three-dimensional information about the external environment, the accuracy and reliability of context recognition are greatly improved. This is far superior to the one-sidedness of relying solely on a single real-time sensor data on the device side, and is the fundamental prerequisite for making correct resource control decisions.

[0058] Depending on the specific context, resource control commands are obtained. These commands are used to adjust the execution parameters of local tasks on the wearable device. These parameters include GPS sampling rate, heart rate sensor sampling frequency, and screen brightness.

[0059] After identifying a specific scenario, the scenario engine and associated strategy module generate corresponding resource control instructions. These instructions are specific, executable device operation commands aimed at adjusting the execution parameters of local tasks on the wearable device to achieve energy saving, enhanced functionality, or optimized user experience. Specific examples include: Scenario: Outdoor cycling, instructions: {“GPS”:“High frequency mode (1Hz)”, “Heart rate sensor”:“Real-time mode”, “Screen”:“Always on (medium brightness)”, “Cellular data”:“Keep connected”}, aiming to ensure the continuity and readability of exercise data recording; Scenario: Deep sleep at night, instructions: {“GPS”:“Off”, “Heart rate sensor”:“Low frequency mode (samples every 5 minutes)”, “Screen”:“Turn off raise-to-wake”, “Notifications”:“Allow only emergency calls”}, aiming to maximize power saving; Scenario: Subway commuting, instructions: {“GPS”:“Low power mode ... The settings, including "Power Consumption Mode (Base Station Based)," "Offline Music Cache," "Preload," and "Vibration Intensity," are designed to address unstable network environments and improve alert performance. In different scenarios, users have vastly different needs and sensitivities to various device functions. The cloud-based optimal decision, based on global information, is executed by issuing commands to the device, enabling dynamic, precise, and automated configuration of device resources. This avoids potential misjudgments that might occur with simple rules based on a single metric on the device's local machine, such as misjudging a vehicle as asleep while it's in a moving car. Thus, while ensuring the core user experience, it significantly extends device battery life and enhances the intelligence level of the user experience.

[0060] Both the rule tables and the context recognition rule base need to be updated regularly and on demand via the cloud to obtain new rule tables and context recognition rule bases in order to adapt to changes in user behavior and device firmware upgrades.

[0061] To ensure long-term effectiveness, the rule tables (used for generating codes) deployed on the device and the context recognition rule base in the cloud are designed to be dynamically updated. The cloud management platform can periodically analyze aggregated anonymous user data to discover new behavioral patterns, and can also fine-tune personalized rules based on individual user data. When the device firmware is upgraded to add new sensors, the rules also need to be updated synchronously to incorporate the new data source. The updated rule tables and context recognition rule base will be securely pushed to the device and cloud engine.

[0062] This gives the entire system the ability to self-evolve, continuously adapting to changing user behavior, individual differences among users, and hardware iterations of the device itself. This ensures the long-term viability and personalized service capabilities of the technical solution, overcoming the drawbacks of rigid rules and difficult upgrades in traditional embedded systems.

[0063] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0064] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud-based intelligent resource control method for wearable devices, characterized in that, Includes the following steps: Step S1: Obtain a data packet by monitoring sensor and application data from the wearable device. The data packet includes multidimensional dynamic attribute encoding and real-time data. Step S2: Obtain the priority through the multidimensional dynamic attribute encoding, and select and allocate a transmission time window for the data packet corresponding to the multidimensional dynamic attribute encoding from the preset transmission strategy according to the priority. Step S3: Send the data packet within the allocated transmission time window; obtain the service quality requirements based on the data packet; and initiate the closed-loop confirmation mechanism based on the service quality requirements. Step S4: Receive the data packet through the cloud, obtain real-time data based on the data packet, perform context recognition and matching on the real-time data, obtain the matching result, and issue resource control instructions to the wearable device based on the matching result to complete the control closed loop.

2. The intelligent resource control method for wearable devices based on cloud computing as described in claim 1, characterized in that, Step S1 includes the following sub-steps: Step S101, the real-time data includes physiological health data, sports environment data, user interaction data, and application-layer specific data; Step S102: Based on the real-time data, obtain context information, and generate the multidimensional dynamic attribute code through a preset rule table based on the context information. The context information includes task identifier and content status, and the multidimensional dynamic attribute code includes task identifier, priority, data load size, time sensitivity, and service quality requirements. Step S103, the task identifier is used to identify the data source; The priority is assigned according to the task identifier and real-time data through the rule table, and the priority includes the highest level, the second highest level, and the normal level; The time sensitivity and quality of service requirements are defined based on the priority and task identifier.

3. The intelligent resource control method for wearable devices based on cloud computing as described in claim 2, characterized in that, The preset rule table specifically includes: Step S104: Establish a mapping relationship between the context information and the priority, time sensitivity and service quality requirements, and match the context information with the rule table to obtain the first matching result; Step S105: Based on the first matching result, assign corresponding priority, time sensitivity and quality of service requirements to the real-time data, and construct the multi-dimensional dynamic attribute code based on the priority, time sensitivity and quality of service requirements.

4. The intelligent resource control method for wearable devices based on cloud computing as described in claim 3, characterized in that, The preset transmission strategy specifically includes: Step S201, the transmission strategy includes a preemptive immediate window strategy, a periodic synchronization window strategy, and an idle time window strategy; Step S202, the preemptive immediate window strategy is to interrupt the transmission of the current low-priority data packet when the priority is the highest, and allocate a transmission time window for the data packet with the highest priority. The periodic synchronization window strategy is as follows: when the priority is the second highest, the corresponding multidimensional dynamic attribute code is obtained according to the data packet; the time sensitivity is obtained according to the multidimensional dynamic attribute code; and the data packet is placed in the queue waiting for the next periodic synchronization window according to the time sensitivity. The idle time window policy is to place the data packet into the idle time window queue when the priority is normal. The idle time window queue is a queue that is only opened when the device is in an idle state.

5. The intelligent resource control method for wearable devices based on cloud computing as described in claim 4, characterized in that, The duration of the transmission time window is calculated based on the data payload size of the data packet and the estimated data packet transmission rate; When allocating the transmission time window, the device resource status vector is also considered. The device resource status vector reflects the current operating status of the wearable device in real time and includes the current battery level, current processor load, and current network signal strength of the wearable device.

6. The intelligent resource control method for wearable devices based on cloud computing as described in claim 5, characterized in that, Step S3 includes the following sub-steps: Step S301: Send the data packet according to the transmission time window; obtain the multidimensional dynamic attribute code according to the data packet; obtain the service quality requirements according to the multidimensional dynamic attribute code; the service quality requirements include reliable transmission and unreliable transmission. Step S302: When the quality of service requirement is reliable transmission, a closed-loop confirmation mechanism is initiated. Step S303: When the quality of service requirement is unreliable transmission, then transmission is performed.

7. The intelligent resource control method for wearable devices based on cloud computing as described in claim 6, characterized in that, The closed-loop confirmation mechanism specifically includes: Step S304: After the data packet is sent, a timer is started. The duration of the timer is set by the time sensitivity value in the multidimensional dynamic attribute encoding. Step S305: According to the duration, the sender waits and listens for an acknowledgment signal from the receiver; Step S306: If an acknowledgment signal is received before the timer expires, the transmission is considered successful. If the timer times out without receiving an acknowledgment signal, the transmission is considered to have failed. Step S307: When a transmission failure is determined, the multidimensional dynamic attribute encoding of the data packet is modified, the priority is increased by one level, a new multidimensional dynamic attribute encoding is obtained, the modified data packet is obtained according to the new multidimensional dynamic attribute encoding, and the modified data packet is resubmitted to the queue as the front end.

8. The intelligent resource control method for wearable devices based on cloud computing as described in claim 7, characterized in that, Step S4 includes the following sub-steps: Step S401: Based on the data packet, obtain real-time data, and obtain historical behavior data and external environment data through the cloud. The historical behavior data includes the user's average daily steps, common exercise time periods, sleep habits and usual location. The external environment data includes the current time, weather conditions and geographical location information. Step S402: The historical behavior data, external environment data, and real-time data are matched using a predefined context recognition rule base to obtain matching results; Step S403: Based on the matching result, obtain the specific context in which the user is currently located.

9. The intelligent resource control method for wearable devices based on cloud computing as described in claim 8, characterized in that, Step S4 further includes obtaining a resource control instruction based on the specific situation. The resource control instruction is used to adjust the execution parameters of the wearable device's local tasks. The execution parameters include the GPS sampling rate, the heart rate sensor sampling frequency, and the screen brightness.

10. The intelligent resource control method for wearable devices based on cloud computing as described in claim 9, characterized in that, Both the rule tables and the context recognition rule base need to be updated regularly and on demand via the cloud to obtain new rule tables and context recognition rule bases in order to adapt to changes in user behavior and device firmware upgrades.

Images