Traffic classifier for service-aware wi-fi operation

Abstract

The present disclosure provides methods, components, devices, and systems for traffic classifiers for service-aware Wi-Fi operations. The techniques described herein support the creation of a common traffic detection model on an access point (AP) or a client. In some examples, the model can reclassify traffic over time to avoid detection failures during periods of atypical traffic patterns for a flow of interest. The traffic classifier can provide traffic detection results and traffic activity such that power saving operations can be enabled. Some aspects more specifically relate to mechanisms by which an AP or a client can select power saving parameters associated with a classified traffic flow to the AP or client.

Description

[0001] Cross-reference to related applications

[0002] This patent application claims U.S. Patent Application No. 18 / 899,813, filed September 27, 2024, entitled "TRAFFIC CLASSIFIER FOR SERVICE AWARE WI-FI OPERATION"; U.S. Patent Application No. 18 / 899,823, filed September 27, 2024, entitled "POWER SAVE PARAMETER SELECTION AT A CLIENT DEVICE IN ACCORDANCE WITH AJOINTEVALUATION OF LATENCY AND POWER CONSUMPTION"; and U.S. Patent Application No. 18 / 899,823, filed February 22, 2024, entitled "TRAFFIC CLASSIFIER FOR SERVICE AWARE WI-FI". This application also claims priority to U.S. Provisional Application No. 63 / 556,748, entitled “Wi-Fi Client Traffic Classifier for Service-Aware Wi-Fi Operations,” filed February 22, 2024, by Katar et al., entitled “Wi-Fi Client Traffic Classifier for Power Saving Operations,” and Indian Provisional Application No. 202441012755, filed February 22, 2024, by Bhattacharya et al., entitled “Power Saver Pargameter Selection at a Client Device in Accordance with a Joint Evaluation of Latency and Power.” The benefit of Indian Provisional Application No. 202441012720, entitled “CONSUMPTION (Selection of power saving parameters at the client device based on a joint assessment of latency and power consumption),” is assigned to the assignee of this application and is expressly incorporated herein by reference. Technical Field

[0003] This disclosure relates generally to wireless communications, and more specifically to a service classifier for service-aware Wi-Fi operations.

[0004] Related technical descriptions

[0005] Wireless communication networks can include various types of wireless communication devices, including network entities such as wireless access points (APs) or base stations (BSs), client devices such as wireless stations (STAs) or user equipment (UEs), and other wireless nodes. These wireless communication devices can communicate with each other via various technologies and wireless communication protocols, including wireless local area networks (WLANs) or Wi-Fi-based protocols, or cellular-based protocols such as 4G, 5G, or 6G. Wireless communication networks can support communication with multiple users by sharing available system resources such as time, frequency, and spatial resources. To achieve features or provide improved performance, wireless communication devices can employ techniques such as orthogonal frequency division multiple access (OFDMA), multiple-user multiple-input multiple-output (MU-MIMO), spatial multiplexing, and beamforming. For greater interoperability, wireless communication networks can support backward compatibility (such as support for legacy wireless communication devices) and forward compatibility (such as support for communication with wireless communication devices compliant with next-generation wireless communication standards).

[0006] Wireless communication devices may communicate using any one or more of these wireless communication technologies and may include wireless stations (STAs), wireless access points (APs), user equipment (UEs), network entities, or other wireless nodes. In some wireless communication networks, traffic classification techniques may include deep packet inspection (DPI), where static rules are used to match packet content with applications. Summary of the Invention

[0007] The systems, methods, and apparatus disclosed herein each have some innovative aspects, and no single aspect is solely responsible for the desired properties disclosed herein.

[0008] An innovative aspect of the subject matter described in this disclosure can be implemented in a method for wireless communication by a wireless node. The method may include: obtaining a set of multiple samples associated with a set of multiple packets including data; detecting one or more transmission service patterns associated with the set of multiple packets based on one or more parameters associated with the set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both; classifying the set of multiple packets according to one or more service types based on the one or more transmission service patterns; and communicating according to the one or more service types.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented in a wireless node for wireless communication. The wireless node may include a processing system comprising processor circuitry and memory circuitry storing code. The processing system may be configured to cause the wireless node to: obtain a set of multiple samples associated with a set of multiple packets including data; detect one or more transmission service modes associated with the set of multiple packets based on one or more parameters associated with the set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both; classify the set of multiple packets according to one or more service types based on the one or more transmission service modes; and communicate according to the one or more service types.

[0010] Another wireless node for wireless communication is described. The wireless node may include: components for obtaining a set of multiple samples associated with a set of multiple packets including data; components for detecting one or more transmission service patterns associated with the set of multiple packets based on one or more parameters associated with the set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both; components for classifying the set of multiple packets according to one or more service types based on the one or more transmission service patterns; and components for communicating according to the one or more service types.

[0011] One innovative aspect of the subject matter described in this disclosure can be implemented in a non-transitory computer-readable medium storing code for wireless communication. The code may include instructions executable by one or more processors to: obtain a set of multiple samples associated with a set of multiple packets including data; detect one or more transmission service modes associated with the set of multiple packets based on one or more parameters associated with the set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both; classify the set of multiple packets according to one or more service types based on the one or more transmission service modes; and communicate according to the one or more service types.

[0012] In some examples of the methods, wireless nodes, and nontransitory computer-readable media described herein, communication based on one or more service types may include operations, features, components, or instructions for outputting scheduling information associated with a set of multiple packets, wherein the scheduling information may be output according to a channel access scheme that may be based on one or more service types.

[0013] The methods described herein, wireless nodes, and some examples of nontransitory computer-readable media may also include operations, features, components, or instructions for obtaining one or more service activities, one or more service loads, or any combination thereof based on one or more transmission service modes, wherein one or more service types, one or more service activities, and one or more service loads may each be associated with a corresponding service flow in a set of multiple service flows, wherein the set of multiple service flows may be associated with a set of multiple samples, and wherein communication includes performing power-saving operations based on one or more service types, one or more service activities, one or more service loads, or any combination thereof.

[0014] Another innovative aspect of the subject matter described in this disclosure can be implemented in a method for wireless communication by a wireless node. The method may include: obtaining information associated with a traffic flow to the wireless node; obtaining indications of a first set of values ​​associated with inactivity timeout and a second set of values ​​associated with a polling period based on a classification of the traffic flow; selecting a first value from the first set and a first value from the second set at the beginning of a first duration based on a latency metric and a power consumption metric both associated with a second duration; and communicating during the first duration based on the first value from at least the first set or the first value from the second set.

[0015] One innovative aspect of the subject matter described in this disclosure can be implemented in a wireless node for wireless communication. The wireless node may include a processing system comprising processor circuitry and memory circuitry storing code. The processing system may be configured to cause the wireless node to: obtain information associated with a traffic flow to the wireless node; obtain indications of a first set of values ​​associated with inactivity timeouts and a second set of values ​​associated with a polling period, based on the classification of the traffic flow; select a first value from the first set and a first value from the second set at the beginning of a first duration, based on latency and power consumption metrics both associated with the second duration; and communicate during the first duration based on the first value from at least the first set or the first value from the second set.

[0016] Another wireless node for wireless communication is described. The wireless node may include: components for obtaining information associated with traffic flows to the wireless node; components for obtaining indications of a first set of values ​​associated with inactivity timeouts and a second set of values ​​associated with a polling period based on the classification of the traffic flows; components for selecting a first value from the first set of values ​​and from the second set of values ​​at the beginning of a first duration based on latency and power consumption metrics both associated with the second duration; and components for communicating during the first duration based on either the first value from the first set or the first value from the second set of values.

[0017] One innovative aspect of the subject matter described in this disclosure can be implemented in a non-transitory computer-readable medium storing code for wireless communication. The code may include instructions executable by one or more processors to: obtain information associated with a traffic flow to the wireless node; obtain indications for a first set of values ​​associated with inactivity timeouts and a second set of values ​​associated with a polling period, based on the classification of the traffic flow; select a first value from the first set and a first value from the second set at the beginning of a first duration based on latency and power consumption metrics both associated with a second duration; and conduct communication during the first duration based on the first value from at least the first set or the first value from the second set.

[0018] The methods described herein, wireless nodes, and some examples of nontransitory computer-readable media may also include operations, features, components, or instructions for outputting frames that include indications that the wireless node may be in a waking state, wherein selecting a first value from a first set of values ​​and selecting a first value from a second set of values ​​may be performed in parallel with the output frame.

[0019] Details of one or more specific embodiments of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. Note that the relative dimensions in the following drawings may not be drawn to scale. Attached Figure Description

[0020] Figure 1 A schematic diagram of an example wireless communication network is shown.

[0021] Figure 2 An example of a signaling diagram supporting a service classifier for service-aware Wi-Fi operations is shown.

[0022] Figure 3 An example of a service-aware Wi-Fi architecture supporting a service classifier for service-aware Wi-Fi operations is shown.

[0023] Figure 4 An example of a service classifier architecture on an access point (AP) that supports a service classifier for service-aware Wi-Fi operations is shown.

[0024] Figure 5 An example of a service classifier architecture on a station (STA) that supports service classifiers for service-aware Wi-Fi operations is shown.

[0025] Figure 6 An example of a service type detection process that supports a service classifier for service-aware Wi-Fi operations is shown.

[0026] Figure 7 An example block diagram is shown that supports a business classifier for service-aware Wi-Fi operation and power-saving operation.

[0027] Figure 8 An example of a model for service detection that supports a service classifier for service-aware Wi-Fi operations is shown.

[0028] Figure 9 An example of a service flow that supports a service classifier for service-aware Wi-Fi operations is shown.

[0029] Figure 10 An example of a real-time business block diagram supporting a business classifier for service-aware Wi-Fi operations is shown.

[0030] Figure 11 An example of a streaming service block diagram supporting a service classifier for service-aware Wi-Fi operations is shown.

[0031] Figure 12A and Figure 12B An example illustration of a random forest model supporting a service classifier for service-aware Wi-Fi operations is shown.

[0032] Figure 13 An example of service detection logic supporting a service classifier for service-aware Wi-Fi operations is shown.

[0033] Figure 14 An example of service classifier features supporting a service classifier for service-aware Wi-Fi operation is shown.

[0034] Figure 15 An example of a reclassification process that supports a service classifier for service-aware Wi-Fi operations is shown.

[0035] Figure 16 An example block diagram is shown that supports a business classifier for service-aware Wi-Fi operation and power-saving operation.

[0036] Figure 17 An example flowchart is shown that supports a service classifier for service-aware Wi-Fi operation and power-saving operation.

[0037] Figure 18 and Figure 19 An example of a communication timeline is shown that supports the selection of power-saving parameters at the client device based on a joint evaluation of latency and power consumption.

[0038] Figure 20 An example of a sleep schedule selected at the client device based on a joint assessment of latency and power consumption parameters is shown.

[0039] Figure 21 and Figure 22 An example block diagram is shown that supports the selection of power-saving parameters at the client device based on a joint evaluation of latency and power consumption.

[0040] Figure 23 An example flowchart is shown that supports the selection of power-saving parameters at the client device based on a joint evaluation of latency and power consumption.

[0041] Figure 24 An example of a classification that supports the selection of power-saving parameters at the client device based on a joint assessment of latency and power consumption is shown.

[0042] Figure 25 A block diagram of an example first wireless communication device supporting a service classifier for service-aware Wi-Fi operation is shown.

[0043] Figure 26 A block diagram of an example second wireless communication device supporting a service classifier for service-aware Wi-Fi operation is shown.

[0044] Figure 27 and Figure 28 A flowchart illustrating an example process that can be performed by a first or second wireless communication device that supports a service classifier for service-aware Wi-Fi operation, or that can be performed at the first or second wireless communication device.

[0045] Figure 29 A flowchart illustrating an example process that can be performed by or at a second wireless communication device that supports a service classifier for service-aware Wi-Fi operation is shown.

[0046] Similar reference numerals and names in the various figures indicate similar elements. Detailed Implementation

[0047] The following description refers to certain specific examples in order to illustrate the innovative aspects of this disclosure. However, those skilled in the art will readily recognize that the teachings herein can be applied in a variety of different ways. Some or all of the examples described can be applied in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, the IEEE 802.15 standard, or Bluetooth as defined by the Bluetooth Special Interest Group (SIG). ® It is implemented in any device, system, or network that transmits and receives radio frequency (RF) signals using one or more of the standards such as Long Term Evolution (LTE), 3G, 4G, 5G (New Radio (NR)), or 6G standards published by the 3rd Generation Partnership Project (3GPP).

[0048] The described examples can be implemented in any suitable device, component, system, or network capable of transmitting and receiving RF signals according to one or more of the following technologies or techniques: Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Orthogonal Frequency Division Multiplexing (OFDM), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Space Division Multiple Access (SDMA), Rate Split Multiple Access (RSMA), Multi-User Shared Access (MUSA), Single-User (SU) Multiple-Input Multiple-Output (MIMO), and Multi-User (MU)-MIMO (MU-MIMO). The described examples can also be implemented using other wireless communication protocols or RF signals suitable for use in one or more of Wireless Personal Area Networks (WPANs), Wireless Local Area Networks (WLANs), Wireless Wide Area Networks (WWANs), Wireless Metropolitan Area Networks (WMANs), Non-Terrestrial Networks (NTNs), or Internet of Things (IoT) networks.

[0049] In some wireless communications, Service-Aware Wi-Fi (SAWF) can provide Quality of Service (QoS) (such as for Wi-Fi 6 and Wi-Fi 7). However, SAWF may lack one or more components: the ability to detect traffic types and identify characteristics (and therefore, QoS requirements). Some traffic classification techniques may include Deep Packet Inspection (DPI), where static rules are used to match packet content with applications. DPI may face several challenges. For example, applications increasingly use security protocols such as HTTPS, SSH, SSL, etc., to ensure user privacy. Additionally or alternatively, high-volume traffic (such as 10+ Gbps) flowing through SAWF may introduce high complexity and hardware costs in real-time inspection and classification. This could be advantageous for traffic classification based on traffic pattern detection, online learning of traffic detection models, configurable service level protocols based on traffic detection results, and the distribution and integration of traffic detection across multiple mesh agents.

[0050] The techniques described in this paper enable the creation of common traffic detection models on wireless communication devices, such as on an AP and clients (such as another AP or STA). For example, by combining two-stage random forest models and temporal autoencoders using data collected simultaneously by both the AP and clients, as well as data collected simultaneously on the downlink and uplink, these techniques can support the training and creation of models (such as artificial intelligence (AI) or machine learning (ML) models) to detect real-time traffic, streaming traffic, and any non-real-time or non-streaming traffic. The model can be trained by feeding both offline information (via stored samples) and online information (such as traffic being sent) to a cloud server using a labeling method that includes one or more atypical portions of the traffic already detected from other parts of the long-duration traffic flow using Flow Classification Service (SCS) QoS characteristics. In some examples, the model can reclassify traffic over time to avoid detection failures during periods of atypical traffic patterns in the flow of interest.

[0051] Additionally or alternatively, the techniques described herein support the configuration of Service Level Agreements (SLAs) based on service detection results. APs can use detection results to configure SLAs and operations for service flows transmitted via Triggered Physical Layer Protocol Data Units (TB-PPDUs) for downlink and uplink, including Enhanced Distributed Channel Access (EDCA), scheduling objectives, and signaling to clients to prioritize services into appropriate Service Identifiers (TIDs) or QoS rules. When clients do not support Differentiated Service Code Points (DSCP) policy installation, APs can provide specific EDCA-based triggers on the uplink. STAs can use detection results to configure SLAs and operations for service flows transmitted via Uplink Single User (SU), including EDCA, and using signaling APs to prioritize services into appropriate TIDs or QoS rules and scheduling objectives in the SCS. In some examples, APs or clients can distribute and integrate service detection across multiple APs in a mesh. For example, APs or clients can create service detection models based on service input data from multiple APs and apply service detection during the inference phase using service inputs and detection results from multiple APs. APs or clients can apply different levels of SAWF operations to streams based on the confidence levels of detection results from multiple APs in the grid.

[0052] In some examples, a service classifier can provide both service detection results and service activity and load information to enable power-saving operations. For instance, a service classifier can provide service detection results and service activity, allowing power-saving operations to be enabled based on a combination of multiple service types, service activities, and / or service loads.

[0053] Additionally or alternatively, the wireless communication device may select power-saving parameters associated with traffic flows classified by the traffic classifier. Such power-saving parameters may include one or more of the following: Inactivity Timeout (ITO) value, Speculative Polling Period (SPP) value, Delivery Traffic Indication Map (DTIM) periodicity, and sleep patterns associated with the SSP value. In some implementations, the wireless communication device may select the ITO and SPP values ​​based on a joint evaluation of latency and power consumption metrics associated with previous decision epochs. For example, by selecting previous ITO and previous SPP values ​​for previous decision epochs, the wireless communication device may incur some penalty (such as cost) in terms of latency and power consumption. The wireless communication device may use such latency and power consumption penalties (or metrics) to calculate (such as determining, selecting, identifying, estimating, predicting, or otherwise obtaining) penalty values. Although derived from a joint evaluation of latency and power consumption metrics, such penalty values ​​can be understood as being associated with previous ITO and previous SPP values, because the selection of previous ITO and previous SPP values ​​results in latency and power consumption penalties.

[0054] Wireless communication devices can calculate various penalty values ​​over time (such as across multiple decision epochs) and store the calculated penalty values, such that each penalty value is associated with a corresponding ITO-SPP value pair. In this way, wireless communication devices can gain a more complete understanding over time of the penalty values ​​associated with different ITO-SPP value pairs and can select the ITO-SPP value pair associated with the relatively smallest penalty value (which can appropriately balance the power-delay tradeoff at the wireless communication device for a given traffic flow).

[0055] Specific implementations of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. For example, by supporting monitoring via a traffic classifier and performing power-saving operations under threshold conditions, wireless communication devices can efficiently gain an understanding of which traffic flows are present and can provide appropriate (e.g., flow-specific) power-latency tradeoffs (including power saving). That is, enabling power saving on a wireless communication device may degrade service performance, but if the power saving is achieved based on conditions that make the degraded service performance suitable for the latency requirements associated with the traffic flow, then the wireless communication device can support both power saving and latency requirements. The configuration for power-saving operations at the client can be based on both service type and service load conditions. For example, the configuration for power-saving operations at the client can be based on performance targets (such as latency) at the client. Furthermore, depending on the activity of strengthening or updating traffic flows, the wireless communication device can be able to keep the active traffic flows at the wireless communication device up-to-date and current, thereby allowing the wireless communication device to update the performance of power-saving operations accordingly and support power-latency tradeoffs accordingly.

[0056] Additionally, by supporting the selection of ITO-SPP value pairs based on penalty values ​​tracked over time for different potential ITO-SPP value pairs, wireless communication devices can efficiently gain an understanding of which ITO-SPP value pairs are relatively more likely to provide suitable (e.g., flow-specific) power-delay tradeoffs (including power savings). Furthermore, by reinforcing or updating this understanding over time, wireless communication devices can be kept up-to-date with environmental or other changes affecting power-delay tradeoffs at the device. This allows the device to dynamically adjust ITO and SPP values ​​based on changing service patterns (even for the same application or the same service type or class) or changing environmental conditions (such as changing congestion profiles). Moreover, wireless communication devices can leverage one or more reinforcement learning (RL) models or algorithms to dynamically adapt to such time-varying changes in a scalable manner, as RL models or algorithms can be able to consider a wide range of changes, classifications, patterns, and network conditions that may otherwise involve the use of many separately defined and maintained tables. Therefore, in addition to achieving power savings while still meeting latency constraints, wireless communication devices can also achieve more efficient memory usage, which can increase the capabilities and user experience associated with the wireless communication device, as well as other benefits.

[0057] Figure 1A schematic diagram of an example wireless communication network 100 is shown. Depending on some aspects, the wireless communication network 100 may be an example of a wireless local area network (WLAN) (such as a Wi-Fi network). For example, the wireless communication network 100 may be a network implementing the IEEE 802.11 wireless communication protocol standard family as defined by the IEEE 802.11-2020 specification or its revisions (including, but not limited to, 802.11ay, 802.11ax (also known as Wi-Fi 6), 802.11az, 802.11ba, 802.11bc, 802.11bd, 802.11be (also known as Wi-Fi 7), 802.11bf, and 802.11bn (also known as Wi-Fi 8)) or at least one of other WLAN or Wi-Fi standards such as those associated with the Integrated Millimeter Wave (IMMW) research group. In some other examples, the wireless communication network 100 may be an example of a cellular radio access network (RAN), such as a 5G RAN or 6G RAN implementing one or more cellular protocols, such as those specified in one or more 3GPP standards. In some other examples, the wireless communication network 100 may include a WLAN that operates in an interoperable or convergent manner with one or more cellular RANs to provide greater or enhanced network coverage to wireless communication devices within the wireless communication network 100, or to enable these devices to connect to the core of the cellular network, such as accessing network management capabilities and functionality provided by the cellular network core. In some other examples, the wireless communication network 100 may include a WLAN that operates in an interoperable or convergent manner with one or more personal area networks (such as networks implementing Bluetooth or other wireless technologies) to provide greater or enhanced network coverage or to provide or implement other capabilities, functionality, applications, or services.

[0058] Wireless communication network 100 may include a number of wireless communication devices, including wireless access points (APs) 102 and any number of wireless stations (STAs) 104. Although in Figure 1Only one AP 102 is shown, but the wireless communication network 100 may include multiple APs 102 (such as in an Extended Service Set (ESS) deployment, an enterprise network, or an AP mesh network), or may not include any APs at all (such as in an Independent Basic Service Set (IBSS) (such as a peer-to-peer (P2P) network or other self-organizing network)). AP 102 may be or represent various different types of network entities, including but not limited to home-networked APs, enterprise-grade APs, single-frequency APs, dual-band synchronous (DBS) APs, tri-band synchronous (TBS) APs, standalone APs, non-standalone APs, software-enabled APs (software APs), and multi-link APs (also known as AP multi-link devices (MLDs)), as well as cellular (such as 3GPP, 4G LTE, 5G, or 6G) base stations or other cellular network nodes (such as Node B, evolved Node B (eNB), gNB, Transmit Receive Point (TRP)) or another type of equipment or apparatus included in the radio access network (RAN), including open RAN (O-RAN) network entities such as central units (CUs), distributed units (DUs), or radio units (RUs).

[0059] Each STA 104 may also be referred to as a mobile station (MS), mobile device, mobile phone, wireless phone, access terminal (AT), user equipment (UE), subscriber station (SS), or subscriber unit, etc. STA 104 can represent a variety of devices such as mobile phones, other handheld or wearable communication devices, netbooks, laptops, tablets, laptops, Chromebooks, augmented reality (AR), virtual reality (VR), mixed reality (MR), or extended reality (XR) wireless headsets or other peripherals, wireless earbuds, other wearable devices, display devices (such as TVs, computer monitors, or video game consoles), video game controllers, navigation systems, music or other audio or stereo devices, remote control devices, printers, kitchen appliances (including smart refrigerators) or other home appliances, remote keys (such as those for passive keyless entry and start (PKES) systems), Internet of Things (IoT) devices, and vehicles, etc.

[0060] The associated set of individual AP 102 and STA 104 may be referred to as the Infrastructure Basic Services Set (BSS), which is managed by the corresponding AP 102. Figure 1Additionally, an example coverage area 108 of AP 102 is shown, which may represent the Basic Service Area (BSA) of wireless communication network 100. The BSA can be identified by STA 104 and other devices via a Service Set Identifier (SSID) and a Basic Service Set Identifier (BSSID), which may be the Media Access Control (MAC) address of AP 102. AP 102 may periodically broadcast beacon frames (“beacons”) including the BSSID to enable any STA 104 within the wireless range of AP 102 to “associate” or reassociate with AP 102 to establish or maintain a corresponding communication link 106 (also referred to hereinafter as a “Wi-Fi link”) with AP 102. For example, the beacon may include an identifier or indication of the primary channel used by the corresponding AP 102, and a Timing Synchronization Function (TSF) for establishing or maintaining timing synchronization with AP 102. AP 102 can provide access to external networks to each STA 104 in the wireless communication network 100 via the corresponding communication link 106.

[0061] To establish a communication link 106 with AP 102, each STA 104 is configured to perform passive or active scanning operations (“scans”) on frequency channels in one or more frequency bands (such as 2.4 GHz, 5 GHz, 6 GHz, 45 GHz, or 60 GHz bands). To perform a passive scan, STA 104 listens for beacons transmitted by the corresponding AP 102 at periodic time intervals (referred to as the Target Beacon Transmission Time (TBTT)). To perform an active scan, STA 104 generates probe requests and transmits these requests sequentially on each channel to be scanned, and listens for probe responses from AP 102. Each STA 104 can identify, determine, detect, or select an AP 102 to associate with based on the scanning information obtained through passive or active scanning, and performs authentication and association operations to establish a communication link 106 with the selected AP 102. The selected AP 102 assigns an association identifier (AID) to STA 104 at the end of the association operation, and AP 102 uses the association identifier (AID) to track STA 104.

[0062] As wireless networks become increasingly prevalent, STA 104 has the opportunity to select from a number of BSSs within its range or from multiple APs 102 that together form an ESS (including multiple connected BSSs). For example, wireless communication network 100 can be connected to a wired or wireless distribution system that enables the connection of multiple APs 102 in such an ESS. Therefore, STA 104 can be covered by more than one AP 102 and can be associated with different APs 102 at different times for different transmissions. Additionally, after associating with an AP 102, STA 104 can periodically scan its surroundings to find a more suitable AP 102 to associate with. For example, STA 104 moving relative to its associated AP 102 can perform a "roaming" scan to find another AP 102 with more desirable network characteristics, such as a larger Received Signal Strength Indicator (RSSI) or reduced traffic load.

[0063] In some examples, STA 104 can form a network without AP 102 or any other equipment besides STA 104 itself. An example of such a network is a self-organizing network (or wireless self-organizing network). A self-organizing network may also be referred to as a mesh network or a peer-to-peer network. In some examples, a self-organizing network can be implemented within a larger network, such as wireless communication network 100. In such examples, while STA 104 may be able to communicate with each other via communication link 106 through AP 102, STA 104 can also communicate directly with each other via direct wireless communication link 110. Additionally, two STA 104 can communicate via direct wireless communication link 110, regardless of whether the two STA 104 are associated with and served by the same AP 102. In such a self-organizing system, one or more STAs among STA 104 can assume the role played by AP 102 in the BSS. Such STA 104 can be referred to as the group owner (GO) and can coordinate transmissions within the self-organizing network. Examples of direct wireless communication links 110 include Wi-Fi direct connections, connections established by using Wi-Fi Tunneling Direct Link Establishment (TDLS) links, and other P2P group connections.

[0064] In some networks, AP 102 or STA 104, or both, can support applications associated with high throughput or low latency requirements, or provide lossless audio to one or more other devices. For example, AP 102 or STA 104 can support applications and use cases associated with ultra-low latency (ULL), such as ULL gaming, or streaming lossless audio and video to one or more personal audio devices (such as peripherals) or AR / VR / MR / XR headsets. In scenarios where a user uses two or more peripherals, AP 102 or STA 104 can support extended personal audio networks that enable communication with these two or more peripherals. Additionally, AP 102 and STA 104 can support additional ULL applications with ULL and high throughput requirements, such as cloud-based applications (such as VR cloud gaming).

[0065] As indicated above, in some implementations, AP 102 and STA 104 may operate and communicate according to one or more of the IEEE 802.11 wireless communication protocol family of standards (via the corresponding communication link 106). These standards define WLAN radio and baseband protocols for the physical (PHY) layer and MAC layer. AP 102 and STA 104 transmit and receive wireless communications to and from each other in the form of PHY Protocol Data Units (PPDUs) (also referred to below as "Wi-Fi communication" or "wireless packets").

[0066] Each PPDU is a composite structure comprising a PHY preamble and a payload in the form of a PHY Service Data Unit (PSDU). The information provided in the preamble can be used by the receiving device to decode subsequent data in the PSDU. In instances where the PPDU is transmitted on a bound channel or a wideband channel, the preamble field may be repeated and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble can be used for other purposes such as packet detection, automatic gain control, and channel estimation. The legacy preamble is also typically used to maintain compatibility with legacy equipment. The format, decoding, and information provided in the non-legacy portion of the preamble are associated with the specific IEEE 802.11 wireless communication protocol to be used to transmit the payload.

[0067] AP 102 and STA 104 in wireless communication network 100 can transmit PPDUs on unlicensed spectrum, which may be a portion of the spectrum including bands traditionally used by Wi-Fi technologies, such as the 2.4 GHz band, 5 GHz band, 6 GHz band, 45 GHz band, and 60 GHz band. Some examples of AP 102 and STA 104 described herein can also communicate in other bands that can support both licensed and unlicensed communication. For example, AP 102 or STA 104, or both, may also be able to communicate on licensed operating bands, where multiple operators may have corresponding licenses to operate in the same or overlapping frequency ranges. Such licensed operating frequency bands may be specified or associated with frequency ranges mapped to or associated with FR1 (410MHz to 7.125GHz), FR2 (24.25GHz to 52.6GHz), FR3 (7.125GHz to 24.25GHz), FR4a or FR4-1 (52.6GHz to 71GHz), FR4 (52.6GHz to 114.25GHz), and FR5 (114.25GHz to 300GHz).

[0068] Each of these frequency bands may include multiple sub-bands and frequency channels (also referred to as sub-channels). The terms "channel" and "sub-channel" may be used interchangeably herein, as each term may refer to a portion of the spectrum within the frequency band (such as a 20MHz, 40MHz, 80MHz, or 160MHz portion of the spectrum) through which communication between two or more wireless communication devices may occur. For example, PPDUs conforming to revisions of the IEEE 802.11n, 802.11ac, 802.11ax, 802.11be, and 802.11bn standards may be transmitted on one or more of the 2.4GHz, 5GHz, or 6GHz frequency bands, each of which is divided into multiple 20MHz channels. Thus, these PPDUs are transmitted on physical channels with a minimum bandwidth of 20MHz, but larger channels can be formed through channel bonding. For example, a PPDU can be transmitted on a physical channel with bandwidths of 40MHz, 80MHz, 160MHz, 240MHz, 320MHz, 480MHz, or 640MHz by bundling multiple 20MHz channels together.

[0069] AP 102 can determine or select the operational or operational bandwidth for STA 104 in its BSS, and select a series of channels within the band to provide that operational bandwidth. For example, AP 102 can select sixteen 20MHz channels that collectively span an operational bandwidth of 320MHz. Within the operational bandwidth, AP 102 typically selects a single primary 20MHz channel on which AP 102 and STA 104 in its BSS monitor contention-based access schemes. In some examples, AP 102 or STA 104 may be able to monitor only a single primary 20MHz channel for packet detection (such as for detecting preambles of PPDUs). Conventionally, any transmission made by AP 102 or STA 104 within the BSS must involve transmission on the primary 20MHz channel. Therefore, in a conventional system, the transmitting device must compete for and win the TXOP on the primary channel in order to make any transmission. However, some APs 102 and STAs 104 that support Ultra-High Reliability (UHR) communication or communication revised according to the IEEE 802.11bn standard can be configured to operate, monitor, compete for, and communicate using multiple primary 20MHz channels. This monitoring of multiple primary 20MHz channels can be sequential, such that in response to determining, identifying, or detecting that a first primary 20MHz channel is unavailable, the wireless communication device can switch to monitoring and competing using a second primary 20MHz channel. Additionally or alternatively, the wireless communication device can be configured to monitor multiple primary 20MHz channels in parallel. In some examples, the first primary 20MHz channel may be referred to as the main primary (M-primary) channel, and one or more additional secondary primary channels may each be referred to as the opportunistic primary (O-primary) channel. For example, if the wireless communication device measures, identifies, identifies, detects, or otherwise determines that the M-primary channel is busy or occupied (e.g., due to overlapping BSS (OBSS) transmissions), the wireless communication device can switch to monitoring and competing on the O-primary channel. In some examples, the M primary channel can be used for beacon transmission and to serve legacy client devices, while the O primary channel can be used by non-legacy (such as UHR or IEEE 802.11bn compatible) devices for opportunistic access to spectrum that may otherwise be underutilized. A wireless node can refer to a wireless communication device, such as an AP (e.g., AP102) or STA (e.g., STA104) communicating via wireless communication network 100.

[0070] The techniques described in this paper enable the creation of common traffic detection models on APs and clients (such as another AP or STA). For example, by combining two-stage random forest models and temporal autoencoders using data collected simultaneously by both the AP and clients, as well as data collected simultaneously from downlink and uplink, these techniques can support the training and creation of models (such as artificial intelligence (AI) or machine learning (ML) models) to detect real-time traffic, streaming traffic, and any non-real-time or non-streaming traffic. The model can be trained by feeding both offline information (via stored samples) and online information (such as traffic being sent) to a cloud server using a labeling method that includes one or more atypical portions of the traffic already detected from other parts of the long-duration traffic flow using Flow Classification Service (SCS) QoS features. In some examples, the model can reclassify traffic over time to avoid detection failures during periods of atypical traffic patterns in the flow of interest.

[0071] Additionally or alternatively, the techniques described herein support the configuration of Service Level Agreements (SLAs) based on service detection results. APs can use detection results to configure SLAs and operations for service flows transmitted via Triggered Physical Layer Protocol Data Units (TB-PPDUs) for downlink and uplink, including Enhanced Distributed Channel Access (EDCA), scheduling objectives, and signaling to clients to prioritize services into appropriate Service Identifiers (TIDs) or QoS rules. When clients do not support Differentiated Service Code Points (DSCP) policy installation, APs can provide specific EDCA-based triggers on the uplink. STAs can use detection results to configure SLAs and operations for service flows transmitted via Uplink Single User (SU), including EDCA, and using signaling APs to prioritize services into appropriate TIDs or QoS rules and scheduling objectives in the SCS. In some examples, APs or clients can distribute and integrate service detection across multiple APs in a mesh. For example, APs or clients can create service detection models based on service input data from multiple APs and apply service detection during the inference phase using service inputs and detection results from multiple APs. APs or clients can apply different levels of SAWF operations to streams based on the confidence levels of detection results from multiple APs in the grid.

[0072] If an application can communicate an SLA, Wi-Fi can include several features to improve the user experience. However, in some wireless communication systems (such as those that do not support the technologies described herein), few of these features are triggered due to a disconnect between Wi-Fi and the application. For example, users may experience greater latency in a wireless communication system due to the lack of an SLA compared to one that communicates an SLA.

[0073] The techniques described in this paper support frameworks for online learning of service detection models. For example, an application processing unit (AP) can collect service statistics and transmit them to the cloud to learn new service types and requirements. When a client requests an Service Controller (SCS) for a stream (such as an Internet Protocol (IP) tuple stream), the AP can examine latency limits and service intervals, as well as throughput, to label services for training. In some examples, services may have strict latency limits and service interval requirements. In such examples, the AP can label services as real-time services and add service trajectories to real-time AIML model training. In some examples, services may have relatively less stringent latency limits but strict throughput requirements, and services may be accompanied by large bursts and idle periods. In such examples, the AP can label services as streaming services and add service trajectories to streaming AIML model training.

[0074] In some examples, models can be trained and created online by labeling traffic samples as training samples using an 802.11 Flow Classification Service (SCS) request from the client. Additionally or alternatively, models can be trained and created online by labeling portions of the traffic flow that are not detected as corresponding traffic types as training samples using an 802.11 SCS request from the client, provided other portions of the traffic flow have been detected as their corresponding traffic types. For example, the model can detect whether one or more portions of the traffic flow correspond to a specific transmission traffic type. Based on observed STA compliance with uplink DSCP policy installation, the AP can provide specific EDCA-based triggers on the uplink for traffic types that require urgent uplink access.

[0075] Based on the business statistics collected over a long period, the AP can examine whether a part of the business activity may have been improperly detected and use the collected data as new training samples to retrain the model with the correct (more accurate) labels. In some examples, the AP can retrain the model with the correct labels based on other positive detections, additional metadata collected for the long-term stream, or both.

[0076] APs, clients (such as STAs), or both can support SLAs utilizing traffic classifiers. For example, an AP or client can configure an SLA in SAWF using traffic detection results. An AP or client can configure an SLA based on ML confidence levels. For example, the decision may not be black and white, as both random forest models and autoencoders can indicate the confidence level of their detection results. If the confidence level is relatively low, the AP or client can start with the best-effort access category (AC_BE) with an SLA. In an example with relatively high confidence, the AP or client can move to the voice access category (AC_VO).

[0077] In some examples, the AP or client can avoid Media Access Channel Service Data Unit (MSDU) reordering when moving from a lower Access Class (AC) to a higher AC. The AP or client can move the MSDU queue and wait for the Media Access Channel Protocol Data Unit (MPDU) to be delivered from the previous (older) TID. In some examples, the AP or client can temporarily change the EDCA settings for the TID.

[0078] The AP can send DSCPs with an UP policy to the STA and use TIDs or QoS to identify flows (such as IP 5-tuples) for the STA's use. In some examples, the STA may not modify the TID queue. Additionally or alternatively, the AP can use a higher AC random backoff engine to send triggers for such flows with higher priority. The AP can prioritize all flows with the same TID belonging to the client, provided that at least one flow is detected to have strict latency requirements.

[0079] In some examples, the client may not support QoS DSCP policy capabilities (such as QoS R2 DSCP policies). In such examples, the host can track the total moving average data rate R of the classified and prioritized uplink flows for the client. The firmware (FW) can estimate the buffer size according to Equation 1:

[0080] Buffer size = max(BSR / QoS control queue size, OFDMA trigger size)

[0081] The Firewall (FW) can track the time elapsed since the last priority-ordered trigger to the peer. In some examples, the FW can set the priority-ordered trigger size according to Equation 2:

[0082] Trigger size = min(BE TID, K) R (Time elapsed since the last service)

[0083] In some examples, K can be set to 2.0, with a minimum of 1. An STA can have both delayed and throughput flows on the same TID, but the STA may not prioritize the delivery of delayed flows in its uplink scheduler. For example, if the ratio of R_prio_flow / R_BE_TID is <0.25 or some other value within an observation window, priority triggering is not established. The host can make this determination to prioritize flows before passing WMI commands down to the FW. In some examples without higher backoff engine triggering, the existing MU EDCA of AC_BE can be a regular EDCA setting when using higher triggering. Additionally or alternatively, when using higher AC triggering, the MU EDCA should be set to the existing MU EDCA of AC_BE (e.g., triggering MU EDCA logic can ignore triggering and uplink responses when determining the MU EDCA setting). For flows configured with service intervals, deterministic triggers can be delivered periodically every service interval. The estimated buffer size can consider the burst size of the deterministic configuration rather than the OFDMA trigger size.

[0084] In some examples (such as in mesh latency FR development), when there are many uplink STAs with enough uplink traffic to prioritize, individual uplink priority prioritization may not work better than no priority prioritization due to high AC aggressive contention.

[0085] In some examples, a higher uplink AC triggers a lower TID buffer state report (BSR). In such examples, the client may support QoS DSCP policy capabilities (such as QoS R2 DSCP policies), and the AP may transmit a Traffic Classification (TCLAS) attribute corresponding to the classified and prioritized uplink flows to the client in the QoS management element of the DSCP policy request frame, so that the client prioritizes uplink flows (such as IP tuple flows) to higher TIDs.

[0086] In some examples, the client may not support QoS DSCP policy capabilities. In such examples, the host can track the total moving average data rate of classified and prioritized uplink flows for the client. The firmware (FW) can estimate the buffer size according to Equation 1. The FW can track the time elapsed since the last prioritized trigger to the peer. In some examples, the FW can set the prioritized trigger size according to Equation 2. In some examples, K can be set to 2.0, with a minimum of 1. STAs can have both delayed and throughput flows on the same TID, but STAs may not prioritize the delivery of delayed flows in their uplink scheduler. For example, if the ratio of R_prio_flow / R_BE_TID is <0.25 or some other value within an observation window, a priority trigger is not established. The host can make this determination to prioritize flows before passing WMI commands down to the FW. In some examples without higher backoff engine triggering, the existing MU EDCA for AC_BE can be a regular EDCA setting when using higher backoff engine triggering.

[0087] Additionally or alternatively, when using a higher AC trigger, the MU EDCA should be set to the existing MU EDCA of AC_BE (e.g., triggering MU EDCA logic can ignore triggers and uplink responses when determining the MU EDCA setting). For flows configured with service intervals, deterministic triggers can be periodically transmitted every service interval. The estimated buffer size can take into account the burst size of the deterministic configuration rather than the OFDMA trigger size.

[0088] In some examples, the client can generate SCS requests. For instance, once configured by the client via the API, the client can establish uplink SCS sessions for the AP (such as TCLAS IE: IP 2-tuple, IP 5-tuple, and QoS IE: uplink TID, uplink service interval, uplink latency limit, and uplink throughput). Once configured by the client via the API, the client can also establish downlink SCS sessions for the AP (such as TCLAS IE: IP 2-tuple, IP 5-tuple, and QoS IE: downlink TID, downlink service interval, downlink latency limit, and downlink throughput).

[0089] The techniques described in this paper enable the distribution and integration of service detection across multiple mesh agents. For example, for a service flow passing through multiple agents (such as APs or clients) in a mesh, multiple agents along the flow's E2E path can provide service pattern information to jointly learn an AIML-based service detection model. Each agent can report the service patterns it observes to the root AP. Based on the service being labeled, the root AP can have an AIML model that acquires features from multiple hops (this can be useful for downlink and uplink service arrival statistics, where downlink and uplink statistics may be perturbed by different Overlapping Basic Service Sets (OBSSs)). In addition to service pattern inputs provided by repeater agents in the mesh, the model on the root AP can also include detection results from repeaters as part of the detection features used for the final determination of service type (such as using voting or some other decision-making method). Once the service detection results are reached at the root AP, the root AP can distribute the detection results to multiple agents for them to apply SAWF operating rules.

[0090] Service classifiers can be used to support power-saving operations and improve reliability. For example, service classifiers can be used to support power-saving operations and improve the reliability of video streaming applications, real-time services (such as voice, video conferencing, and / or gaming), and / or back-end services at client devices.

[0091] In some wireless communication systems, wireless communication between AP 102 and its associated STA 104 can be secure. For example, AP 102 or STA 104 can establish a security key to protect its own wireless communication with other devices, and this security key can be used to encrypt the contents of data frames and management frames. In some examples, fields within the MAC headers of control frames and data frames or management frames, or both, can also be protected via encryption or via integrity checks, such as by generating a Message Integrity Check (MIC) targeting one or more relevant fields.

[0092] Access to a shared wireless medium is typically managed by a Distributed Coordination Function (DCF). With DCF, there is generally no centralized master device allocating time and frequency resources for the shared wireless medium. Instead, a wireless communication device (such as an AP102 or STA 104) can wait for a specific period and contend for access to the wireless medium before being permitted to transmit data. DCF is implemented using time intervals, including slot times (or “slot intervals”) and inter-frame gaps (IFS). IFS provides priority access for control frames used for proper network operation. Transmission can begin at slot boundaries. Different variations of IFS exist, including Short IFS (SIFS), Distributed IFS (DIFS), Extended IFS (EIFS), and Arbitrated IFS (AIFS). Values ​​for slot times and IFS can be provided by appropriate standard specifications, such as one or more of the IEEE 802.11 series of wireless communication protocol standards.

[0093] In some examples, wireless communication devices (such as AP 102 or STA 104) can implement DCF using Carrier-Sensed Multiple Access (CSMA) with Collision Avoidance (CA) (CSMA / CA) technology. According to this technology, before transmitting data, the wireless communication device can perform an idle channel assessment (CCA) and determine (such as identifying, detecting, probing, calculating, or operating) whether the relevant wireless channel is idle. CCA includes both physical (PHY-level) carrier sensing and virtual (MAC-level) carrier sensing. Physical carrier sensing is accomplished by measuring the received signal strength of a valid frame, comparing this strength to a threshold to determine (such as identifying, detecting, probing, calculating, or operating) whether the channel is busy. For example, if the received signal strength of the detected preamble is higher than a threshold, the medium is considered busy. Physical carrier sensing also includes energy detection. Energy detection involves measuring the total energy received by the wireless communication device, regardless of whether the received signal represents a valid frame. If the detected total energy is higher than a threshold, the medium is considered busy.

[0094] Virtual carrier sensing is implemented using a Network Allocation Vector (NAV), which effectively serves as the duration before a wireless communication device can contend for access, even in the absence of detected symbols or even when the detected energy is below a relevant threshold. The NAV is reset each time a valid frame not addressed to the wireless communication device is received. When the NAV reaches 0, the wireless communication device performs physical carrier sensing. If the channel remains idle for the appropriate Inception Frequency (IFS), the wireless communication device initiates a backoff timer, which represents the duration during which the device senses the medium is idle before being allowed to transmit. If the channel remains idle until the backoff timer expires, the wireless communication device becomes the owner (or "owner") of the Transmission Opportunity (TXOP) and can begin transmitting. The TXOP is the duration during which the wireless communication device can transmit frames on the channel after it has "won" contention for the wireless medium. The duration of the TXOP can be indicated in the U-SIG field of the PPDU. Conversely, if one or more carrier sensing mechanisms in the carrier sensing mechanism indicate that the channel is busy, the MAC controller within the wireless communication device will not allow transmission.

[0095] Each time a wireless communication device generates a new PPDU for transmission in a new TXOP, it randomly selects a new backoff timer duration. The available distribution of numbers that can be randomly selected for the backoff timer is called the contention window (CW). Different CW and TXOP durations exist for each of the following four access classes (AC): Voice (AC_VO), Video (AC_VI), Background (AC_BK), and Best Effort (AC_BE). This allows for prioritizing specific types of traffic within the network.

[0096] In some other examples, wireless communication devices (such as AP 102 or STA 104) may contend for access to the WLAN's wireless medium according to an Enhanced Distributed Channel Access (EDCA) procedure. Random channel access mechanisms (such as EDCA) can provide a greater probability of high-priority traffic gaining medium access than low-priority traffic. Wireless communication devices using EDCA can classify data into different access categories. Each AC can be associated with a different priority level and can be assigned a different range of random backoff (RBO), making higher-priority data more likely to win TXOPs (e.g., by assigning a lower RBO to higher-priority data and vice versa). While EDCA increases the likelihood that low-latency data traffic will gain access to the shared wireless medium during a given contention period, the unpredictable outcome of medium access contention operations may prevent low-latency applications from achieving specific levels of throughput or meeting specific latency requirements.

[0097] In some implementations, wireless communication devices (such as client devices, such as STA 104) may support one or more mechanisms, according to which the wireless communication device can select a set of power-saving parameters associated with traffic flows to the wireless communication device and communicate according to this set of power-saving parameters. Such power-saving parameters may include ITO values, SPP values, DTIM periodicity, and sleep modes. According to some example implementations, the wireless communication device may utilize one or more classification models or algorithms and one or more selection models or algorithms. Classification models or algorithms may be associated with classifying traffic flows into traffic classes, and in some examples, with mapping traffic classes to traffic type buckets. Selection models or algorithms may include one or more RL models or algorithms as part of a larger RL framework. Selection models or algorithms may take information associated with traffic type buckets (corresponding to active traffic flows to the wireless communication device) as input and may output indications for one or more power-saving parameters.

[0098] Wireless communication devices can communicate (such as transmit or monitor) based on power-saving parameters obtained from a selection model or algorithm. In some examples, such communication may include, or be associated with, transmitting uplink frames based on speculative wake-up after a duration associated with an SPP value output from the selection model or algorithm. Additionally or alternatively, such communication may include monitoring a channel or link, continuously for a duration associated with an ITO value output from the selection model or algorithm, and entering a sleep state after the duration associated with the ITO value has expired, or be associated with it.

[0099] Furthermore, according to one or more of the specific embodiments disclosed herein, the wireless communication device may support one or more signaling mechanisms, such as frame transmission or frame reception. For example, the wireless communication device may send to AP 102 an indication of classifying traffic flows into traffic classes or an indication of traffic type buckets corresponding to traffic classes via one or more of various types of uplink frames. Additionally or alternatively, the wireless communication device may send to or receive from AP 102 or another wireless communication device any one or more parameters, values, variables, or factors indicating that the wireless communication device may use them for any one or more of one or more classification models or algorithms or one or more selection models or algorithms. Additionally or alternatively, the wireless communication device may send to AP 102 or another wireless communication device information indicating the ability of the wireless communication device to support any one or more of the power-saving parameter selection schemes disclosed herein. Additionally or alternatively, the wireless communication device may receive from AP 102 or another wireless communication device information indicating the activation or deactivation of any one or more of the power-saving parameter selection schemes disclosed herein.

[0100] The various aspects and techniques described herein can be implemented, at least in part, using artificial intelligence (AI) programs, such as those that include machine learning (ML) or artificial neural network (ANN) models. Example ML models may include mathematical representations or definitions of computational capabilities for inferring from input data based on patterns or relationships identified in the input data. As used herein, the term "inference" may include one or more of decision, prediction, determination, or value, which may represent the output of the ML model. Computational capabilities may be defined based on certain parameters of the ML model, such as weights and biases. Weights may indicate a relationship between certain input data and certain outputs of the ML model, and biases are offsets that may indicate the starting point of the ML model's output. Example ML models that operate on input data may start at an initial output based on biases and update their outputs based on a combination of input data and weights.

[0101] In some respects, ML models can be configured to provide computational capabilities for wireless communication. Such ML models can be configured with weights and biases to perform traffic flow classification or power-saving parameter selection. Thus, during device operation, the ML model can receive input data (such as information associated with traffic flows, a set of ITO-SPP candidate values, delay constraints, congestion values, estimated power consumption, or estimated delay) and make inferences based on weights and biases (such as traffic classification or selection of ITO-SPP value pairs).

[0102] ML models can be deployed in one or more devices (such as access points, network entities, and client devices) and can be configured to enhance various aspects of wireless communication systems. For example, ML models can be trained to identify patterns or relationships in data corresponding to networks, devices, or air interfaces. ML models can support operational decisions involving one or more aspects associated with wireless communication devices, networks, or services. For example, ML models can be used to support or improve aspects such as signal decoding / decoding, network routing, energy saving, transceiver circuit control, frequency synchronization, timing synchronization, channel state estimation, channel equalization, channel state feedback, modulation, demodulation, device location, beamforming, load balancing, operational and management functions, and security.

[0103] ML models can be characterized by a learning type that generates a specific type of learning model that performs a particular type of task. For example, different types of machine learning include supervised learning, unsupervised learning, semi-supervised learning, RL, etc. ML models can be used to perform various tasks, such as classification or regression, where classification refers to determining one or more discrete output values ​​from a predefined set of output values, and regression refers to determining continuous values ​​that are not constrained by predefined output values. For example, a classification ML model configured according to aspects of this disclosure can produce outputs including indications of business classes, indications of latency configurations, or indications of business type buckets. Some example ML models configured to perform such tasks include ANNs, such as convolutional neural networks (CNNs) and recurrent neural networks (RNNs), transformers, diffusion models, regression analysis models (such as statistical models), large language models (LLMs), decision tree learning (such as predictive models), random forest models, support vector networks (SVMs), and probabilistic graphical models (such as Bayesian networks), multi-armed gambling machine models, etc. In some aspects of this disclosure, two advantageous ML models for processing input data are the random forest model and the multi-armed gambler model, wherein the random forest model can improve the efficiency of processing input data by classifying the traffic flow, and wherein the multi-armed gambler model can improve the latency-power tradeoff by selecting one or more power-saving parameters.

[0104] This paper illustrates, through examples, how one or more tasks or problems in wireless communication can benefit from the application of one or more ML models to support traffic flow classification and power-saving parameter selection. For ease of discussion, ML models configured with ANNs are used; however, it should be understood that other types of ML models can be used instead of ANNs. Therefore, unless explicitly stated otherwise, the topic of ML models is not necessarily intended to be limited to ANN solutions. Furthermore, it should be understood that, unless otherwise specified, terms such as “AI / ML model,” “ML model,” “trained ML model,” “ANN,” “model,” and “algorithm” are intended to be used interchangeably.

[0105] Figure 2 An example of a signaling diagram 200 supporting a service classifier for service-aware Wi-Fi operation is shown. Signaling diagram 200 may include communication 210 between a first wireless communication device 205-a and a second wireless communication device 205-b. In some examples, each wireless communication device 205 may be as follows: Figure 1Examples of AP 102 or STA 104 illustrated and referred to in this figure are shown. For example, a first wireless communication device 205-a may be a first STA 104, and a second wireless communication device 205-b may be a second STA 104. In some examples, the first wireless communication device 205-a may be a first STA 104, and the second wireless communication device 205-b may be a first AP 102. In some other examples, the first wireless communication device 205-a may be a first AP 102, and the second wireless communication device 205-b may be a first STA 104. Alternatively, the first wireless communication device 205-a may be a first AP 102, and the second wireless communication device 205-b may be a second AP 102.

[0106] In some examples, the first wireless communication device 205-a and the second wireless communication device 205-b may communicate services 220 via communication 210. For example, the first wireless communication device 205-a may send services 220 (such as data or information) to the second wireless communication device 205-b, or vice versa. As discussed herein, the term "communication" may refer to the wireless communication device 205 outputting, acquiring, sending, and / or receiving information or signaling to / from another wireless communication device 205, the wireless communication device 205 itself, or both. For example, one or more components of the wireless communication device 205 may communicate with one or more other components of the wireless communication device 205. Additionally or alternatively, one or more components of the wireless communication device 205 may communicate with another wireless communication device 205.

[0107] In some examples, such as reference Figure 3 Further described, the wireless communication device 205 can receive service 220 according to QoS scheduling and one or more channel access schemes. In some examples, one or more channel access schemes can be applied to service 220 based on the classification or type of service 220.

[0108] In some examples, each wireless communication device in the wireless communication apparatus may include a service classifier 215, which can detect the service type and characteristics of service 220. For example, a first wireless communication device 205-a may include a first service classifier 215-a, and a second wireless communication device 205-b may include a second service classifier 215-b. See reference... Figure 4 and Figure 5 In further detail, AP 102 and STA 104 can each implement the service classifier 215.

[0109] Each business classifier in business classifier 215 can detect business types and characteristics based on one or more processes (such as filtering, feature extraction, class detection, and flow priority ranking), as referenced. Figure 6 As described. Additionally or alternatively, the service classifier 215 can support power-saving operations based on the detected service type and characteristics, as described in the reference. Figure 7 As described.

[0110] In some examples, each service classifier 215 can detect the service type based on a combination of real-time service models and streaming service models, as shown in the reference. Figure 8 and Figure 9 Further detailed description. Additionally or alternatively, the business classifier 215 may use a combination of a random forest model and one or more autoencoders corresponding to the respective business type, as described in the reference... Figures 10 to 13 As described. In some examples, the service classifier 215 can obtain service characteristics from service 220, which allows the wireless communication device 205 to configure SLAs for different service flows. See reference... Figure 14 As described, the business classifier 215 can obtain business characteristics from one or more samples of business 220. In some examples, the business classifier 215 can validate the business classification via a reclassification stream, as described in the reference. Figure 15 As described.

[0111] Additionally or alternatively, each wireless communication device in wireless communication device 205 may enable one or more power-saving operations based on the service detection results of each service classifier in service classifier 215. For example, as referenced Figure 16 Further described, the service classifier results can enable power management logic, which enables one or more power-saving operations. In some examples, different types of services 220 may be more suitable for power-saving operations (such as non-streaming services). Therefore, as referenced... Figure 17 As described, the service classifier 215 can periodically check for the presence of service flows to enable or disable power-saving operations.

[0112] In some examples, the first wireless communication device 205-a and the second wireless communication device 205-b may exchange one or more signaling frames 225. See reference... Figure 18 and Figure 19 Further described, one or more signaling frames 225 may be associated with power transitions (such as from wake-up to sleep or from sleep to wake-up) for the respective wireless communication device 205. For example, the first wireless communication device 205-a and the second wireless communication device 205-b may support active (wake-up) and inactive (sleep) periods based on different applications and services 220 associated with those applications, as described in reference Figure 20 The subject of discussion. See reference. Figures 21 to 24 As further described, the output of the service classifier 215 can provide a basis for each corresponding wireless communication device 205 to select power-saving parameters for power transition (such as selecting power-saving parameters for entering or exiting sleep).

[0113] Figure 3 An example of a service-aware Wi-Fi architecture 300 supporting a service classifier for service-aware Wi-Fi operations is shown. Figure 3 An example of a SAWF providing QoS to multiple STAs 104 is illustrated. For example, the SAWF can receive classified service flows 305 (such as streaming, video, etc.). Classified services can enter one or more flow queues 310. In some examples, flow queues 310 may include one or more QoS criteria (such as QoS requirements). Based on one or more flow queues 310, services can be scheduled via QoS scheduling 315. Services can be scheduled according to one or more channel access schemes 320 and can be directed (provided) to one or more STAs 104.

[0114] In some other wireless communication systems, SAWF may not support the ability to detect traffic type, identification characteristics, or both (and therefore not support QoS criteria in one or more flow queues 310). For example, DPI may include matching packet content to applications using static rules. However, some applications may increasingly use security protocols such as HTTPS, SSH, SSL, etc., to ensure user privacy, which may not be supported by DPI. Additionally or alternatively, high-volume traffic (such as 10+ Gbps) flowing through SAWF may introduce high complexity and hardware costs in real-time inspection and classification.

[0115] As described in this paper, ML-based business classification can include learning the temporal and frequency characteristics of business generated by the application (such as the absence of deep grouping checks, resulting in fewer CPU cycles). ML-based business classification avoids per-group checks (which have lower costs compared to DPI), is cryptographically independent, and offers robust performance.

[0116] Orthogonal Frequency Division Multiple Access (OFDMA), Multiple-User Multiple-Input Multiple-Output (MU-MIMO), and scheduled access techniques can utilize one or more channel access schemes 320. These one or more channel access schemes 320 can correspond to different transmission priorities. For example, a back-end access class (AC_BK) can be associated with low priority, while a voice access class (AC_VO) can be associated with high priority (such as relative to AC_VO). Most applications can use a best-effort access class (AC_BE). ML-based service classification can support the more efficient use of multiple access classes.

[0117] Figure 4 An example of a service classifier architecture 400 on an AP that supports a service classifier for service-aware Wi-Fi operation is shown. Figure 4 This example illustrates a high-level architecture for SAWF on an AP with a service classifier 415. The AP can be as shown in the reference. Figure 1 An example of the described AP 102. The business classifier architecture 400 on the AP may include software 405 (such as client software) that interfaces with the SAWF 420 via one or more application programming interfaces (APIs) 410.

[0118] In some examples, software 405 can obtain telemetry information of classified flows 425 (such as service flows) from SAWF 420. Based on the received telemetry information of classified flows 425, software 405 can output one or more de-prioritized classified flows 430 to SAWF 420. Additionally or alternatively, software 405 can output indication 435 to enable or disable service classifier 415. In some examples, software 405 can obtain one or more classification results 440 (such as service classification results) from service classifier 415. Service classifier 415 can also output indication 445 for service priority ranking to SAWF 420.

[0119] Business classifier 415 may include a combination of a random forest ML model and a temporal autoencoder to achieve ML-based business classification. For example, business classifier 415 may utilize a random forest ML model and a temporal autoencoder to output one or more classification results 440. In some examples, one or more APIs 410 may enable and disable business classifier 415 (e.g., based on received indication 435). One or more APIs 410 may enable customers to view business classifier decisions and telemetry information of classified flows (e.g., telemetry information of classified flows 425). In some examples, the AP may adjust the service priority ranking decision of the classified flows. For example, the AP may adjust the service priority ranking based on an indication 445 obtained from SAWF 420.

[0120] Figure 5 An example of a service classifier architecture 500 on a STA that supports service classifiers for service-aware Wi-Fi operations is shown. Figure 5 This example illustrates a high-level architecture for SAWF on a STA with a business classifier 510. The STA can be as shown in the reference. Figure 1An example of the described STA 104. In some examples, API 505 (such as a client API for service prioritization) and business classifier 510 can install a service prioritization strategy into service prioritization module 515. Service prioritization module 515 can install one or more classifiers (such as IP tuple-based, DSCP-based) in packet classifier 520. Packet classifier 520 can receive one or more packets 525 and classify one or more packets 525 according to the classifiers installed by service prioritization module 515. In some examples, packet classifier 520 can output classified packet information to one or more flow queues 535.

[0121] Additionally or alternatively, the service priority sequencing module 515 can communicate with the SCS 530 and one or more flow queues 535 to provide one or more MSDU queues, install one or more QoS protocols, or both. In some examples, the SCS 530 can output SCS requests for downlink and uplink flows to the AP 102. The AP 102 can be as shown in the reference... Figure 1 An example of the described AP 102. AP 102 can output DSCP policy requests for uplink flows to SCS 530.

[0122] In some examples, one or more flow queues 535 can output services (such as services associated with one or more packets 525) to one or more schedulers 540. One or more schedulers 540 can schedule services according to one or more channel access schemes 545. For example, scheduler 540-a can schedule services according to voice access category, scheduler 540-b can schedule services according to video access category, and scheduler 540-c can schedule services according to best-effort category.

[0123] Business classifier 510 may include a combination of a random forest ML model and a temporal autoencoder to achieve ML-based business classification. Business classifier 510 on the STA may include an AIML model trained based on business patterns shared between the STA and APs (such as APs with business classifiers). In some examples, API 505 (such as a customer API) can enable and disable business classifier 510. API 505 allows customers to view business classifier decisions and telemetry information for classified flows. In some examples, AP 102 can adjust service priority ranking decisions for classified flows.

[0124] Figure 6 An example of a service type detection process 600 supporting a service classifier for service-aware Wi-Fi operation is shown. Figure 6An example of a basic service type detection process is illustrated. For instance, the service type detection process may include a filtering step 605, a feature extraction step 610, a service type detection step 615, and a SAWF flow priority ranking step 620. In some examples, the filtering step 605 may include a decision flow for extracting features based on User Datagram Protocol (UDP) and a lifetime duration threshold, such as from a service sample. For example, based on the detection of a new flow (such as a new IP 5-tuple flow), the filtering step 605 may determine whether UDP is present. If not, the filtering step 605 may take no action. If UDP is present, the filtering step 605 may continue to determine whether the lifetime is greater than a threshold. In some examples, the threshold may be a minimum duration (such as in seconds). If the lifetime is greater than the threshold, the filtering step 605 may proceed to the feature extraction step 610. If the lifetime does not meet the threshold (is less than the threshold), the filtering step 605 may take no action.

[0125] Feature extraction step 610 may include extracting one or more parameters associated with transmitted packets and data. The one or more parameters may include data rate, packet rate, maximum packet size, minimum packet size, or half-standard packet size. The one or more parameters may be associated with uplink, downlink, or both. For example, within a 600ms window, feature extraction step 610 may extract ten samples of features from the window, including downlink data rate and uplink data rate, as well as other parameters.

[0126] In some examples, the service classifier can perform the service class detection step 615 based on the feature extraction step 610. The service class detection step 615 may include a random forest ML model, a temporal autoencoder, or a combination thereof. Based on the service class detection, a service access category can be assigned in the SAWF flow prioritization step 620.

[0127] Figure 7An example block diagram 700 supporting a traffic classifier for service-aware Wi-Fi operation and power-saving operation is shown. Block diagram 700 can be implemented by a traffic classifier at a wireless communication device, such as a client device (such as a STA). For example, as illustrated in the example of block diagram 700, the traffic classifier can identify and classify traffic flows at the wireless communication device. The identification and classification of traffic flows may include one or more steps illustrated in the example of block diagram 700. For example, the traffic classifier may filter (such as prune) traffic flows in a filtering step 705, extract features of the identified traffic flows in a feature extraction step 710, input the extracted features into a traffic class detection model (such as including a random forest model and / or an autoencoder) in a traffic class detection step 715, and perform power management using the output of the traffic class detection model in a power management operation 720 (such as a power-saving operation). In other words, the traffic classifier can classify the identified traffic flows via a filtering step 705, a feature extraction step 710, and / or a traffic class detection step 715, and the classified traffic flows can be input into power management operation 720 (such as optimized power management (OPM)). The wireless communication device can perform power management operation 720 based on the classified traffic flows.

[0128] In some examples, the business classifier may include or be associated with a random forest model, which may be an example machine learning algorithm. In some aspects, a random forest can be understood as an ensemble learning algorithm that uses an ensemble of decision trees to make predictions. Multiple decision trees can be created using different random subsets of data and features. Each decision tree can provide an opinion on how to classify a business flow into a specific business class. In some aspects, predictions are made by the business classifier (and similarly by the wireless communication device) by computing predictions for each decision tree and selecting the most popular result as the output. Therefore, in some aspects, the output of the business classifier may be the most popular or most frequently chosen classification result obtained by the business classifier (such as a random forest). Thus, the business classifier can take one or more business flows as input and can classify each of the one or more business flows into a set of one or more distinct business classes. In some aspects, different business classes may be associated with different latency constraints for each flow. In some aspects, latency constraints may include latency added due to power savings. The business classifier may be implemented in host software.

[0129] Figure 8 An example of a model 800 for service detection is shown, which supports a service classifier for service-aware Wi-Fi operations. Figure 8An example of a combination of individual artificial intelligence and / or machine learning (AIML) models for real-time (RT) service detection and streaming service detection is illustrated. Real-time services can be associated with a relatively short window of samples 805, and streaming services can be associated with a relatively long window of samples 820. For example, a model for real-time services (such as voice, video calls, or games) can detect real-time services using statistics within a 1.2-second window of samples (such as short window sample 805). As an illustrative example, given five samples for detection, the final detection time could be 6 seconds. Short window sample 805 can be input into RT service model 810. RT service model 810 can determine the type of service. For example, RT service model 810 can determine voice / video call / game service 815 based on short window sample 805.

[0130] In some examples, the RT service model 810 can determine that the service is not a real-time service. In such examples, the streaming service model 825 can be used. The streaming service model 825 can use statistics within a 30-second long window (such as long window sample 820) to distinguish video streaming from other services. For example, the streaming service model 825 can distinguish video streaming service 830 from other services (such as voice, video calls, games, or some other service 835).

[0131] Figure 9 An example of a service flow 900 that supports a service classifier for service-aware Wi-Fi operations is shown. Figure 9 Examples of multiple service detection elements in a wireless device (such as an AP, client, or both) are illustrated. For instance, a new service can be detected at 905 and monitored according to the TCP protocol (by the operating system to determine if the flow is still active) for up to duration 910. Based on the determination that the flow is still active within duration 910, the wireless device can initiate real-time interactive service detection 915 (such as VoIP, video conferencing, gaming, etc.).

[0132] An AP or client can use a short double sampling window to perform real-time interactive operational detection 915 for grouping statistics and feature extraction from one or more samples 920. In some examples, the short double sampling window can span one sample, such as the first sample 920-a. In some other examples, the short double sampling window can span two samples, such as the first sample 920-a and the second sample 920-b.

[0133] In some examples, the service can be a streaming service associated with a service pattern different from that of a real-time service. For example, an AP or client can determine that a service flow is not a real-time interactive service based on one or more samples 920 (via multiple sample voting). In such examples, the AP or client can detect downlink streaming services via downlink streaming detection 925 and can use a relatively large sampling window 930 for burst statistics and packet statistics feature extraction. In some examples, the relatively large sampling window 930 can span more than two samples (such as including two or more third samples 920-c). For example, downlink streaming detection 925 can include a busy period 935 for slot-based service statistics feature extraction. In some examples, the AP or client can use a service classifier to detect multiple service classes (such as real-time, streaming, or others).

[0134] Figure 10 An example of a real-time service block diagram 1000 supporting a service classifier for service-aware Wi-Fi operation is shown. Figure 10 An example of real-time interactive traffic detection is illustrated. In some examples, the traffic classifier may include a combination of a real-time traffic random forest model 1005 and one or more autoencoders 1010. The real-time traffic random forest model 1005 can identify whether a real-time traffic stream is a voice traffic stream, a video conferencing traffic stream, a gaming traffic stream, or a background traffic stream. Although in Figure 10 The example illustrates voice traffic, video conferencing traffic, gaming traffic, and backend traffic, but it is understandable that the real-time traffic random forest model can group traffic into additional groups.

[0135] A combination of a real-time service random forest model 1005 and one or more autoencoders 1010 can receive samples of ML features and detect real-time services (such as VoIP, video conferencing, gaming, or others). In some examples, the real-time service random forest model 1005 can input the identified service flow into a corresponding autoencoder 1010 for the corresponding service flow type. For example, the real-time service random forest model 1005 can identify a first service flow as a voice service flow and thus input the voice service flow into the autoencoder 1010-a corresponding to the voice service. In some examples, autoencoder 1010-b may correspond to a video conferencing service, and autoencoder 1010-c may correspond to a gaming service. One or more autoencoders 1010 can confirm the identification made by the real-time service random forest model 1005 or otherwise reclassify the service flow into an unknown category. For example, the autoencoder 1010 can enhance the pruning of unknown services that may be different from the service type specifically trained for (such as those not in the training samples for the service classifier). The combination of the real-time service random forest model 1005 and the autoencoder 1010 is an illustrative example. Real-time business random forest model 1005 and autoencoder 1010 can be used according to... Figure 10 Other methods not illustrated herein can be combined to achieve the same results in real-time interactive business detection.

[0136] Figure 11 An example of a streaming service block diagram 1100 supporting a service classifier for service-aware Wi-Fi operation is shown. Figure 11 An example of streaming service detection is illustrated. In some examples, the service classifier may include a combination of a streaming service random forest model 1105 and one or more autoencoders 1110. A streaming service block diagram 1100 can identify whether a streaming service flow is a streaming service flow or a background service flow. Although in Figure 11 The example illustrates streaming service flows and background service flows, but it is understood that the streaming service random forest model can group service flows into additional groups.

[0137] A combination of a streaming service random forest model 1105 and one or more autoencoders 1110 can receive samples of ML features and detect streaming services. In some examples, samples of ML features can be considered as samples from a reference... Figure 10The real-time service random forest model 1005 described is unknown. In some examples, the streaming service random forest model 1105 can input the identified service flow into the corresponding autoencoder for the corresponding service flow type. For example, the streaming service random forest model 1105 can identify a first service flow as a streaming service flow and thus input the streaming service flow into the autoencoder 1110 for streaming services. The corresponding autoencoder 1110 can confirm the identification made by the streaming service random forest model 1105, or otherwise reclassify the service flow to an unknown category. The combination of the streaming service random forest model 1105 and the autoencoder 1110 is an illustrative example. The streaming service random forest model 1105 and the autoencoder 1110 can be... Figure 11 Other methods not illustrated herein can be combined to achieve the same results in streaming service detection.

[0138] Figure 12A and Figure 12B Examples of random forest models supporting service classifiers for service-aware Wi-Fi operations are shown in diagrams 1200-a and 1200-b. For example, Figure 12A An example of a one-stage random forest model scheme 1200-a is given, and Figure 12B An example of a two-stage random forest model scheme 1200-b is illustrated. A random forest model can output the probability that a sample corresponds to a label. For example, a random forest model can receive sample 1205 (such as a sample of a service) and determine whether sample 1205 is known or unknown to the model (such as a known service or an unknown service). In some examples, a random forest model can determine whether sample 1205 is known or unknown based on whether one or more portions of multiple samples correspond to one or more service types. Figure 12A This could include a model B 1210 trained to categorize services of unknown type that are of no interest. For example, model B 1210 could be a random forest model trained on non-real-time and non-streaming services. If model B 1210 can classify services into known services 1220 and unknown services 1215 based on sample 1205.

[0139] Random forest model scheme 1200-b can be added to random forest model scheme 1200-a to become a two-stage random forest model. For example, Figure 12BThis can include Model B 1210 and Model A 1230, where Model A 1230 can be trained to categorize services of interest. After classifying services into unknown services 1215 and known services 1220, the two-stage random forest model can further classify the services. For example, the two-stage random forest model can determine whether the (deterministic) probability of unknown service 1215 meets a first threshold (greater than a certain threshold). r_u If the probability meets the first threshold, the business is classified as unknown business 1225. If the probability does not meet the first threshold, the business can be input into model A 1230.

[0140] In addition to the existing land or alternative land, the two-stage random forest model can determine whether the probability of the known business 1220 meets the second threshold (such as being greater than 1220). r_k1 If the probability meets the second threshold, the service can be classified as known service 1235. If the probability does not meet the second threshold, the service can be input into model A 1230. For example, model A 1230 could be a random forest model trained using real-time services and streaming services that do not have unknown types.

[0141] Model A 1230 can determine whether a business is a known business 1240, and Model A 1230 can classify a business as an unknown business 1245 or a known business 1250. Each of the unknown or known business categories can be further distinguished based on meeting one or more thresholds. For example, based on the probability of meeting a third threshold (less than...). r_k2 The business can be an unknown business (1245). Based on satisfying the fourth threshold (greater than...). r_k2 The business can be a known business (1250). In some examples, the combination of model B (1210) and model A (1230) can improve the detection of businesses of interest and businesses of no interest.

[0142] Figure 13 An example of service detection logic 1300 supporting a service classifier for service-aware Wi-Fi operation is shown. Figure 13An example of combined AIML model detection logic is illustrated. For instance, a service classifier may include multiple random forest models, such as a real-time service model 1310 and a streaming service model 1345, as well as an autoencoder. The service classifier can sample services using short-window samples 1305 and can detect whether a service is associated with a real-time service, a streaming service, or another type of service. For example, a short-window sample 1305 may be input into the real-time service model 1310, which can determine at 1315 whether the service associated with a short-window sample 1305 is known (such as known services, such as VoIP, video conferencing, games, etc.). If the service is unknown, the real-time service model 1310 can classify the service as unknown. If the service is known, an autoencoder corresponding to the known service type can be selected via autoencoder selection 1320. For example, a known game service can be input into a game autoencoder. The selected autoencoder can determine at 1325 whether the service is known or unknown (such as whether the game service is known or unknown).

[0143] Based on the business being determined to be known or unknown at point 1325, business detection logic 1300 can determine at point 1330 whether the business has been detected as a known class (business type). M Threshold count. For example, if a gaming service is detected as having reached a known threshold... M If so, the business can be classified as a game business. If not, the business detection logic 1300 can determine whether it has been used at 1335. N The number of samples. If not, the service can be input to the beginning of the logic flow at the real-time service model 1310. If so, the service can be combined with long window samples 1340, and the service can be input to the streaming service detection logic using relatively long window samples.

[0144] For example, a service can be input into a streaming service model 1345. The streaming service model 1345 can determine at 1350 whether the service is known (e.g., a known streaming service). If the service is determined to be unknown, it can be classified as an unknown service. If the service is determined to be known, an autoencoder corresponding to the known service type can be selected at 1355. The selected autoencoder can further determine at 1360 whether the service is known or unknown. If the service is known, it can be classified as a streaming service (and if it is unknown, it is classified as an unknown service).

[0145] Figure 14 An example of a service classifier feature 1400 that supports a service classifier for service-aware Wi-Fi operation is shown. Figure 14An example of AIML business classifier features is shown. The business classifier can be associated with, or implement, an artificial intelligence (AI) and / or machine learning (ML) model. The business classifier can collect one or more samples within one or more sampling windows. For example, the business classifier can collect... N Grouped logs of 5 samples (e.g., N=5 samples, including the first sample 1405-a and the second sample 1405-b). For example, a business classifier can collect data for IP 5-tuple streams. N The sample (up to the ) N 1405 samples N Each sample may include grouping information (such as statistics, features) within a dual sampling window of durations T1 and T2 (e.g., T1 = 300 ms, T2 = 1.2 s). That is, the business classifier may collect features for a first sample 1405-a within at least the first duration (T1) and the second duration (T2), where the first sample 1405-a includes features associated with the first and second durations (e.g., for real-time interactive business). While the business classifier is illustrated as collecting samples within a dual sampling window (e.g., the first and second durations), it is understood that the business classifier may collect samples within fewer or more windows.

[0146] For example, packet information may include burst statistics and / or packet statistics (for downlink streaming services). Burst statistics may include burst duration (minimum, maximum, average), burst size (minimum, maximum, average), and / or burst count (number). Packet statistics may include packet size (minimum, maximum, average), packet interval time (minimum, maximum, average), packet rate, data rate, number of packets per time slot during busy periods (minimum, maximum, average), and / or number of bytes per time slot during busy periods (minimum, maximum, average).

[0147] Figure 15 An example of a reclassification process 1500 supporting a service classifier for service-aware Wi-Fi operations is shown. Figure 15 An example of business classifier enhancement for reclassification is shown. The business classifier can attempt to classify businesses. For example, starting at 1505, the business classifier can reclassify businesses associated with a first business category, classify businesses not associated with a business category, or both.

[0148] In some examples, the service classifier can perform reclassification attempts. For instance, when a stream is classified as a real-time service or a video downlink streaming service at 1510 (such as a classification with low confidence compared to other service streams), the service classifier can perform a reclassification attempt. Based on the stream classification at 1510, the service classifier can determine at 1515 whether the service type is known. If the service type is known, the service classifier can proceed to 1520 to determine if the service is classified with high confidence. If the service type is unknown, the service classifier can proceed to 1525 to determine if the service has already been classified a threshold number (such as N times). If the service classifier has already classified the service a threshold number of times, the service classifier can terminate the reclassification process 1500 at 1535. If the service classifier has not yet classified the service a threshold number of times, the service classifier can proceed to 1530 to reclassify the service. For example, the service classifier can perform a threshold number of reclassification attempts (such as N times, such as N=6). The business classifier can perform a number of reclassification attempts equal to a threshold number of reclassification attempts.

[0149] Reclassification attempts can be separated using a timer set at 1530. For example, a first reclassification attempt can occur at a first time, and a second reclassification attempt can occur at a second time, where the first and second times are separated by a threshold duration. The service classifier may include timers set to the threshold duration, where the timers are reset after the reclassification attempt. For example, the service classifier may include multiple timers associated with different service types, such as video streaming (e.g., T_reclassification_interval_VideoStreaming, which can be 60 seconds) and / or real-time services (e.g., T_reclassification_interval_RT_traffic, which can be 10 seconds).

[0150] Alternatively, the business classifier may perform fewer reclassification attempts than a threshold number based on the association between the classification and a threshold confidence level. That is, the business classifier may suppress the execution of additional reclassification attempts based on the association between reclassification attempts and a threshold confidence level. For example, the business classifier may end the reclassification process 1500 at 1535 based on determining that the business is classified with relatively high confidence at 1520. Additionally or alternatively, the business classifier may reclassify businesses (such as groupings) based on the business type confidence level being less than or equal to a threshold confidence level at 1520.

[0151] Additionally or alternatively, if a flow is classified as unknown, the service classifier may perform a threshold number of reclassification attempts while the flow is classified as unknown. That is, the service classifier may reclassify a service until the flow is detected or until the number of reclassification attempts reaches a threshold. For example, the service classifier may suppress additional reclassification attempts for a flow based on whether the flow has been detected (classified).

[0152] Figure 16 An example block diagram 1600 supporting a service classifier for service-aware Wi-Fi operation and power-saving operation is shown. Block diagram 1600 can be implemented by a service classifier at a wireless communication device, such as a client device. Service classifier 1610 can indicate service conditions under which power management can be applied at the client device.

[0153] In some examples, multiple streams may coexist at the client. In other words, the client may be associated with at least a first stream for a first time period and a second stream for a second time period, wherein the first and second time periods at least partially overlap. Each stream may include one or more corresponding stream statistics 1605 (such as per-stream statistics). In some examples, the client may perform power management operations based on the stream statistics 1605 received by the service classifier 1610.

[0154] Power management can be applied based on service type, service load, or both. For example, a client can apply power management based on whether the service type is video downlink streaming, non-latency-sensitive service (such as real-time service), or one of both. For example, power management can be applied based on the presence of video downlink streaming and / or the absence of latency-sensitive service. Additionally or alternatively, a client can apply power management based on service load below a threshold (such as unknown background service load). For example, the threshold could be a service rate below R kbps (such as 300 kbps). Additionally or alternatively, a client can apply power management based on service load being below or equal to a threshold.

[0155] The service classifier 1610 can monitor services and report information associated with service flows. For example, the service classifier can periodically (e.g., every T seconds, e.g., 3 seconds) track the throughput of service flows (e.g., unknown service flows). Additionally or alternatively, the service classifier 1610 can track the throughput of service flows over a previous time period (e.g., the most recent T seconds). In some examples, the service classifier 1610 can output a first indication 1615 indicating the presence of video downlink streaming, a second indication 1620 indicating the presence of real-time service, a third indication 1625 indicating the total number of unknown downlink and uplink service flows, or any combination thereof. In some examples, the client can perform power management based on one or more of the first indication 1615, the second indication 1620, or the third indication 1625 obtained from the power management logic 1630. For example, the power management logic 1630 can enable power management based on receiving one or more indications.

[0156] Figure 17 An example flowchart 1700 supporting a traffic classifier for service-aware Wi-Fi operation and power-saving operation is shown. Flowchart 1700 can be implemented by a traffic classifier at a wireless communication device, such as a client device. Starting at 1705, the traffic classifier can perform a flow activity check. In some examples, the traffic classifier can classify the flow at 1710. Based on the flow classification at 1710, the traffic classifier can set an activity check timer 1715.

[0157] The service classifier can periodically monitor inactivity in service flows (e.g., via an activity check timer set at 1715). For example, different service flows can be associated with corresponding activity check timers at the service classifier. For instance, a video streaming flow can be associated with a first timer (e.g., T_activity_interval_VideoStreaming=10s), a real-time service flow can be associated with a second timer (e.g., T_activity_interval_RT_traffic=6s), and a background service flow can be associated with a third timer (e.g., T_activity_interval_background=6s). In other words, the service classifier can use timers for activity checks. In some examples, the activity check can examine one or more activities associated with a service flow.

[0158] Based on the expiration of the corresponding activity check timer, the service classifier can check for activity at 1720. The service classifier can determine whether a service is active or inactive at 1725. In some examples, a service flow can be considered active based on a throughput exceeding a threshold percentage (such as 10%) initially detected by the service classifier. In other examples, a service flow can be inactive based on a throughput below a threshold percentage.

[0159] The service classifier can indicate the presence of a service flow type for power management at 1730 based on whether the service flow is active. For example, the service classifier can suppress indicating that a service flow is eligible for power management when the service flow is inactive, but indicate that the service flow is eligible for power management at the client based on the service flow becoming active (such as based on indicating the presence of the flow at 1730).

[0160] In some examples, the service classifier can suppress indications of a detected service flow's presence at 1735 based on the flow becoming inactive. For instance, a service flow might become inactive when a user on a client device switches to a different application. In other examples, the service classifier can stop indicating the presence of a detected service flow based on the client's operating system.

[0161] Figure 18 Example communication timeline 1800 is shown, supporting the selection of power-saving parameters at the client device based on a joint evaluation of latency and power consumption. Communication timeline 1800 illustrates communication between an AP and a STA, which can be respectively... Figure 1 Examples of AP 102 and STA 104 illustrated and referenced in the figure are shown. Communication timeline 1800 can be implemented by one or more APs and one or more STAs for one or both of uplink and downlink communication.

[0162] Communication timeline 1800 includes beacons (such as beacon frames) without a Service Indication Map (TIM) and beacons with a TIM setting. In some respects, a TIM can be an example of a Delivery TIM (DTIM). A DTIM can be associated with Wi-Fi beacon-assisted wake-up (where the device potentially sleeps for the remainder of the duration). The power contribution (such as power or energy consumption) of DTIM and device listening operations can be approximately 55% to up to approximately 80% of the device's power. Some platforms or systems are designed to reduce the magnitude of power consumption (this can be understood as a reduction on the Y-axis). In other words, the Y-axis value or metric can be associated with the current power consumption for each period (such as a listening period, a DTIM period, a short sleep period, or a transmit or receive period). Additionally or alternatively, some platforms or systems designed to improve power savings may reduce or limit (such as configuring or optimizing) the time spent waking up or otherwise in active operation (this can be understood as a reduction on the X-axis). In other words, the X-axis value or metric can be associated with the duration of each time period (such as the duration of a listening period, DTIM period, short sleep period, or transmit or receive period). Reducing or limiting (or optimizing) the time spent waking up can include reducing the total listening duration or increasing the total DTIM duration (such as increasing the DTIM period) while meeting (such as satisfying) application / business requirements / constraints.

[0163] In some aspects, the power management (PM) components of some existing systems can use signaling frame 1805 (which may be referred to as a security signaling frame) for power transitions (such as for all power transitions). Such signaling frame 1805 can be a Quality of Service (QoS) null data packet (NDP) with the power management (PM) bit set to either 1 (PM=1) or 0 (PM=0). For example, wireless communication devices (such as STA 104 or client devices) can send signaling frames 1805 (such as 1805-a, 1805-b, 1805-c, 1805-d, or 1805-e) to indicate the PM status of the wireless communication device. PM indication can be combined with regular PM or speculative PM (in... Figure 18 The example shown is associated with "spec PM" or can be understood as a regular PM or speculative PM. If a wireless communication device wants to attempt to receive any downlink packets that AP 102 may currently be buffering for the wireless communication device, the wireless communication device can transmit a speculative PM.

[0164] In some respects, wireless communication devices (as or via PM components) can use signaling frame 1805 for speculative acquisition and regular mode changes. Furthermore, in some respects, switching to PM=0 (such as via QoS NDP) allows aggregation for buffered traffic downloads, as opposed to single packet acquisition via power-saving (PS) polling (PS-POLL) frames. In some respects, a reduced ITO lookup table can be used for speculative wake-up to increase power efficiency (such as optimizing power).

[0165] Communication timeline 1800 illustrates various ITO durations and various actions or operations. For example, in some aspects, ITO 1810-a can be set to 25 milliseconds (ms). In some examples, such an ITO 1810-a duration can be an ITO estimated by a congestion metric (such as a congestion value). A 25ms ITO can be understood as a regular ITO. Furthermore, in some examples, a wireless communication device (such as a STA) can perform speculative acquisition during an ITO 1810-b duration (such as a 25ms ITO duration). In some examples, the ITO can be set to 15ms. A 15ms ITO can be understood as a reduced ITO. In some aspects, a wireless communication device (such as a STA) can communicate during a 15ms ITO 1810-c duration, using a speculatively reduced ITO, or otherwise communicating based on a speculatively reduced ITO. During the time duration between signaling frames (such as a 40ms time duration), the wireless communication device may perform conditional (such as optional) speculation 1815 (such as a first conditional speculation 1815-a and a second conditional speculation 1815-b).

[0166] Figure 19 Example communication timeline 1900 is shown, supporting the selection of power-saving parameters at the client device based on a joint evaluation of latency and power consumption. In some respects, communication timeline 1900 illustrates AP and STA (such as those provided by...) Figure 1 The communication between AP 102 and STA 104 (illustrated and described in this figure) is illustrated. For example, communication timeline 1900 illustrates communication (such as sending or receiving) of downlink packets, uplink packets, beacon frames (with or without TIM settings, such as including or excluding TIM), and NDP (with PM indication or bits set to 0 or 1). Communication timeline 1900 further illustrates the time periods during which wireless communication devices (such as STAs) are active. Additionally, communication timeline 1900 illustrates various time durations associated with one or more power-saving parameters. Such power-saving parameters include ITO and SPP, or parameters indicating ITO and SPP. Such power-saving parameters may also include beacon sleep intervals. In some examples, power-saving parameters (such as SSP) may be greater than or equal to the delivery DTIM interval.

[0167] In some respects, if no downlink or uplink packets are present or if a specific timeout duration (such as the duration of ITO) is reached, the wireless communication device can enter a "deep" sleep. Furthermore, the wireless communication device can wake up at a DTIM epoch to check the availability of downlink data. A DTIM epoch can be the point in time at which a beacon frame including a DTIM (such as a DTIM beacon frame) is expected to be received. As described herein, it can be understood that an epoch (such as a time epoch, DTIM epoch, decision epoch, previous epoch, etc.) can refer to a duration (such as the first duration, the second duration, the previous duration). Such beacon frames can be received according to a DTIM interval, which can be a multiple of the beacon interval, such as... The beacon interval is set to, for example, 100ms. In some respects, the duration of the ITO and the duration of the spec ITO can be selected from multiple lookup tables. Such lookup tables may include lookup tables associated with the Wi-Fi Latency Manager (WLM) (with configuration settings including Normal, Medium, Low, and Ultra-Low Latency (ULL)), lookup tables associated with congestion values, or lookup tables associated with operating frequency bands.

[0168] In some scenarios, ITO and spec ITO selections can be associated with static tables (ensuring that the SPP remains unchanged). Furthermore, WLM configuration settings may not be used by most applications, leading to frequent selection of the normal latency table by the wireless communication device (even if multiple tables are expected to be maintained at the wireless communication device). Additionally, in some scenarios, sleep parameters (such as power-saving parameters) may not explicitly depend on the ongoing application or incoming service mode, potentially resulting in a certain amount of unnecessary power consumption for at least some applications or service modes.

[0169] Figure 20 Example sleep schedules 2000, 2001, and 2002 are shown to support the selection of power-saving parameters at the client device based on a joint assessment of latency and power consumption. Example sleep schedules 2000, 2001, and 2002 can illustrate time periods associated with active operation (such as "on" time periods) and time periods associated with inactivity (such as "sleep" time periods). In other words, the wireless communication device 2010 can be in an "on" state during the time periods associated with active operation, and can otherwise be in an "off" or "sleep" state.

[0170] Different applications may have different sleep schedules. For example, such as... Figure 20As illustrated in the example, a first application 2005-a may be associated with sleep schedule 2000, a second application 2005-b may be associated with sleep schedule 2001, and a third application 2005-c may be associated with sleep schedule 2002. Data arrival in some WLANs may be determined by application type (such as service mode), media congestion, or backend latency (such as being associated with or based on them).

[0171] Furthermore, different applications may be associated with different latency constraints (such as different latency expectations or requirements). In some respects, latency constraints may conflict with power constraints (such as power expectations or requirements). For example, for latency-sensitive applications (such as gaming), a 100ms sleep may affect latency. Further, for symmetric service applications (such as Voice over Internet Protocol (VoIP)), a 100ms sleep may be impractical due to frequent uplink service interruptions. Generally speaking, static (inflexible) trade-offs between latency and power can lead to network or device inefficiencies.

[0172] According to some example implementations of this disclosure, wireless communication devices can utilize the output of a traffic classifier to determine, identify, select, compute, ascertain, or otherwise obtain information indicating delay constraints (such as delay expectations, needs, or requirements) for each of one or more traffic flows. Wireless communication devices can use reinforcement learning (RL) algorithms to configure (such as optimize) delay / power tradeoffs in real time. Wireless communication devices can also track potentially changing environments (which may involve or include changes associated with delay constraints of traffic or variations in congestion levels) and the changing "power costs" of different low-power activities over generations (which may involve or include listening power, S2W / W2S overhead power, or shallow sleep power modes). According to such example implementations, wireless communication devices can achieve power savings superior to other power-saving mechanisms.

[0173] Based on such traffic classifiers and RL algorithms, wireless communication devices can select values ​​for one or more power-saving parameters. These power-saving parameters can include ITO, SPP, DTIM periodicity, and sleep mode. ITO can relate to how long the wireless communication device listens when PM=1 and can be set to any value including 10ms, 20ms, 30ms, 50ms, 100ms, or 200ms. An ITO that is too small (such as 10ms) may result in relatively low power consumption at the potential cost of latency. An ITO that is set too large (such as 100ms) may result in lower latency at the potential cost of power consumption. SPP can relate to how long the wireless communication device remains in a sleep state when PM=0. SPP can be set to any value including 10ms, 20ms, 30ms, or 50ms. Outputs associated with the SPP value may include indications of whether speculative polling should be used, indications of which power-saving mode to enter between speculative polling sessions, or indications of how long the SPP value should be.

[0174] DTIM periodicity can have similar advantages and disadvantages to ITO and can be set to any value including 100ms, 200ms, 300ms, 400ms, 500ms, 600ms, 700ms, 800ms, or 900ms. A DTIM associated with a DTIM1 setting may correspond to a 100ms DTIM, a DTIM associated with a DTIM2 setting may correspond to a 200ms DTIM, and so on. Therefore, for example, DTIM1 may be associated with lower latency at the potential cost of power consumption. Further, for example, DTIM3 or higher may be associated with relatively lower power consumption at the potential cost of latency. Sleep modes can indicate light sleep (LS) or deep sleep (DS). LS can be selected when the SPP duration is relatively short. DS can be selected for relatively long sleep periods, such as DTIM initiation. For example, DS can be selected when the SPP duration is greater than or equal to a threshold SPP value.

[0175] Figure 21 An example block diagram 2100 is shown to support the selection of power-saving parameters based on a joint evaluation of latency and power consumption at the client device. Block diagram 2100 may illustrate the selection of one or more power-saving parameters 2120, including ITO, SPP, DTIM periodicity, or sleep modes (such as SPP sleep mode). Block diagram 2100 may include a service classifier 2105 that classifies traffic flows into service classes 2110, and an RL algorithm 2115 that jointly configures (such as jointly optimizes) latency and power based on the results (such as outputs) of the service classifier 2105. The output of the RL algorithm 2115 may include information indicating ITO, SPP, DTIM periodicity, or sleep modes (such as SPP sleep mode).

[0176] In some examples, the business classifier 2105 may include or be associated with a random forest model, which may be an example machine learning algorithm. In some aspects, a random forest model can be understood as an ensemble learning algorithm that uses an ensemble of decision trees to make predictions. Multiple decision trees can be created using different random subsets of data and features. Each decision tree can provide an opinion on how to classify a business flow into a specific business class. In some aspects, the business classifier 2105 (and similarly, the wireless communication device) makes predictions by computing predictions for each decision tree and selecting the result with the most votes as output. Therefore, in some aspects, the output of the business classifier 2105 may be the classification result with the most votes or the most common outcome obtained by the business classifier 2105 (such as by a random forest model). Thus, the business classifier 2105 can take one or more business flows 2125 as input and can classify each of the one or more business flows 2125 into a set of one or more different business classes 2110 (such as video, games, or voice). In some aspects, the different business classes 2110 may be associated with different latency constraints for each flow. In some respects, latency constraints may include latency added due to power savings. In some respects, the service classifier 2105 may be implemented in host software.

[0177] Based on the results obtained from the business classifier 2105, the RL algorithm 2115 can perform joint configurations (such as joint optimization) of latency and power individually or jointly for various business classes 2110. In some aspects, the algorithm can satisfy a latency budget for a given business class 2110, and after satisfying the budget, latency can be traded off for power savings. In some aspects, the RL algorithm 2115 can be implemented as a multi-armed gambler. A multi-armed gambler can be understood as an algorithm according to which a decision maker (such as a selector) iteratively selects one of a plurality of fixed choices (which can be understood as arms or actions) when the properties of each choice may only be partially known at the time of assignment, evaluation, or selection and may become better understood over time. The RL algorithm 2115 can be understood as an RL framework and may include or be associated with one or more RL models / estimaters. The RL algorithm 2115 can jointly evaluate latency and power for a given traffic flow 2125 (such as according to traffic flow classification) and can output one or more power saving parameters 2120 for traffic flow 2125 based on the joint evaluation. Such one or more power saving parameters 2120 may include ITO value, SPP value, DTIM periodicity, or sleep mode (such as SPP sleep mode).

[0178] Figure 22An example block diagram 2200 is shown that supports the selection of power-saving parameters based on a joint evaluation of latency and power consumption at the client device. Block diagram 2200 may be associated with the selection of one or more power-saving parameters 2225, including ITO, SPP, DTIM periodicity, or sleep modes (such as SPP sleep mode). Block diagram 2200 may include a service classifier that categorizes traffic flows into service classes and an RL algorithm (such as an RL framework) that jointly configures (such as jointly optimizes) latency and power based on the results (such as the output) of the service classifier. The output of the RL algorithm may include information indicating ITO, SPP, DTIM periodicity, or sleep modes (such as SPP sleep mode).

[0179] Block diagram 2200 may include at least a first phase associated with latency constraints identifying the application with the lowest latency tolerance (such as the traffic flow with the lowest latency tolerance) and a second phase associated with identifying one or more power saving parameters 2225 (such as ITO-SPP value pairs, DTIM periodicity, and sleep modes when the latency constraints are met). Host framework 2205 may include a traffic classifier and a Wi-Fi latency manager (WLM). The traffic classifier may classify traffic flows or applications into traffic classes 2210. Traffic classes 2210 may include video calls, audio calls, video streaming, games, or unknown. If traffic class 2210 is unknown, the wireless communication device may skip the RL framework and perform different types of PM operations for the traffic flow. The WLM may provide ULL or normal (such as normal latency) output.

[0180] In some implementations, a business classifier framework can spend a specific amount of time collecting sample data and extracting features to learn new business types. In some aspects, the business classifier can learn a new business type (once) for each new incoming stream (e.g., on a per-stream basis). After learning the new business type, the business classifier can spend a specific amount of time per sample for detection or prediction.

[0181] The outputs of the WLM and the service classifier can be mapped to service type buckets 2215. Service type buckets 2215 may include video call buckets, ULL buckets, audio call buckets, game buckets, and streaming buckets. Therefore, incoming services are categorized on a per-stream basis, with the service classifier output mapped to the corresponding service type bucket. Service type buckets 2215 may include, or be associated with, information indicating latency constraints, DTIM periods, and the ITO-SPP set (such as a set of candidate values ​​for each of the ITO and SPP). In some respects, the WLM ULL configuration can override the service classifier classification. For example, if the WLM output indicates a ULL configuration, the ULL service type bucket can be selected.

[0182] The table below illustrates some example power-saving parameters associated with various types of business classifiers. In some examples, web browsing and gaming benefit from ML-based power-saving parameter selection due to the dynamic nature of the businesses categorized for these business flows. For instance, each game has a different business model, and web browsing depends on the type of upcoming feed (video content vs. text / images).

[0183]

[0184] Wireless communication devices can use characteristics associated with service type buckets to select one or more power-saving parameters 2225. For example, a wireless communication device can select DTIM periodicity based on a service type bucket corresponding to a service flow, such as a service flow most sensitive to latency. In some implementations, the wireless communication device can provide an ITO-SPP set and latency constraints to the RL framework 2220 for selecting one or more of the ITO value, SPP value, and sleep mode. The RL framework 2220 may include one or more RL models. For example, the RL framework 2220 may include a power penalty estimator, a latency estimator, and a congestion estimator, which provide information to a model associated with a joint configuration of power and latency, such as joint evaluation or joint optimization.

[0185] A power penalty estimator can track, calculate, select, identify, predict, determine, extract, or otherwise obtain information associated with power consumption in different processes or operations of a wireless communication device. Such processes may include sleep-to-wake (S2W) transitions, wake-to-sleep (W2S) transitions, or the transmission of frames indicating PM=0 or PM=1. The power penalty estimator can also track baseline currents associated with one or more different sleep modes. Therefore, the power penalty estimator can provide a power penalty for selected ITO-SPP combinations, such as selected ITO-SPP value pairs. The power penalty estimator can be associated with estimations or calculations of power consumption during listening, sleep, and PM0 / 1 NDP phases. Furthermore, the power penalty estimator can track chip-specific configurations associated with transition times and durations, baseline currents, etc.

[0186] The power penalty estimator can collect one or more statistics. Such statistics can be collected after the wireless communication device exits power saving (PM=0 confirmed). These statistics may include sleep time, transition time (S2W or W2S), transmit time, receive time, total time, and listening time. Sleep time can be the period between the previous PM=1 NDP and the current PM=0 NDP, and may include both long sleep and SPP duration. Transmit time may include the duration of all transmitted packets, packet length, and rate-related factors, and can be used to determine, select, identify, estimate, or predict the accurate listening time. Receive time may include the total duration of all received packets, packet length, and rate-related factors, and can be used to determine, select, identify, estimate, or predict the accurate listening time. Total time may include the duration between the previous time epoch (the start of the current time epoch). Listening time can be calculated as Listening Time = Total Time - Sleep Time - Rx Time - Tx Time, and can be further classified into different types of listening operations, such as Normal Power Listening (NPL) and Low Power Listening (LPL). Wireless communication devices can use counters to track the duration of LPL.

[0187] The power penalty estimator can calculate the epoch energy (P) according to the following formula: epoch energy (P) = (listening time) (Listening current) + (Sleep time) Sleep current + (transition time) (Transition current). Additionally, the power penalty estimator can use an epoch energy normalization factor (P0), which can be the power consumed in transmitting an NDP PM=0 / 1 frame. The epoch energy normalization factor can depend on one or more of the following factors, including the selected sleep mode (such as light sleep or deep sleep), S2W or W2S duration and power, minimum ITO duration and listening power, maximum SPP duration and sleep power, and NDP PM=0 / 1 transmission duration.

[0188] Wireless communication devices can perform power penalty estimation using P and P0 at decision epochs, which can be understood as the beginning of a time epoch. In some aspects, statistics can be collected and averaged at each PS exit. Decision epochs at which a new ITO-SPP selection is performed may include several such PS exits with statistics collected (and averaged) over the time elapsed from the previous decision epoch to the current decision epoch.

[0189] The power penalty estimator can use (such as maintaining) one or more static chip-specific configurations, including one or more transition times, one or more transition currents, one or more sleep currents, one or more power penalty normalization factors, one or more listener currents, and a shallow sleep entry threshold. One or more transition times can be measured in microseconds or milliseconds and may include S2W duration for deep sleep, S2W duration for shallow sleep, W2S duration for deep sleep, and W2S duration for shallow sleep. One or more transition currents can be measured in battery milliamperes (mAB) and may include S2W current for deep sleep, W2S current for deep sleep, S2W current for shallow sleep, and W2S current for shallow sleep. One or more sleep currents can be measured in mAB and may include a minimum current limit for deep sleep and a minimum current limit for shallow sleep. One or more power penalty normalization factors may include a normalization factor for deep sleep and a normalization factor for shallow sleep. One or more listener currents can be measured in mAB and may include NPL current and LPL current. The threshold for entering light sleep, which can be measured in microseconds or milliseconds, can be the duration of Special Phase Count (SPP). Sleep durations below this SPP will trigger light sleep. In some aspects, deep sleep can be associated with DTIM sleep entry. Furthermore, in some deployment scenarios, a power penalty normalization factor (P0) can be calculated at runtime.

[0190] The latency estimator can estimate the average latency of incoming service patterns and can provide latency penalties for selected ITO-SPP combinations (such as selected ITO-SPP value pairs). In some aspects, the latency estimator can compute latency estimates for each ITO-SPP value pair and can use estimates and constraints (such as latency constraints provided by service type buckets) to compute latency penalties. The latency estimator can maintain one or more (static) configurations. Such configurations may include a minimum random backoff (RBO) threshold table based on congestion metrics (which may be equivalently referred to herein as congestion factor or congestion value), a maximum RBO threshold table based on congestion factors (RBO_MAX_THRESHOLD table), and a latency adder table based on congestion factors. By "based on congestion metrics," such thresholds can be understood as being able to be changed, configured, or tuned according to congestion.

[0191] The delay estimator can initialize RBO_MIN_THRESHOLD and RBO_MAX_THRESHOLD based on congestion metrics and can begin tracking "buffered" and "new" packets after the wireless communication device exits the PS (e.g., after PM=0 is transmitted and acknowledged). The delay estimator can track arrival timestamps and calculate the inter-packet interval for received packets. The inter-packet interval can be such that inter-packet interval = (current received packet timestamp - previous received packet timestamp). If the first packet after PM=0 is transmitted is sent, the inter-packet interval can be the duration between the previous transmitted packet and the first received packet. If the first packet after PM=0 is transmitted is received, the inter-packet interval can be the duration between PM=0 (the wireless communication device exits the PS) and the arrival time of the current received packet.

[0192] If the inter-packet interval of the first packet is less than RBO_MIN_THRESHOLD, the wireless communication device (via the delay estimator) can stop tracking the received inter-packet interval (and all packets from this point onward (including the current packet) can be considered "new packets"). If the inter-packet interval of the first packet is greater than RBO_MIN_THRESHOLD, the wireless communication device (via the delay estimator) can continue tracking the received inter-packet interval. Furthermore, if the inter-packet interval is greater than RBO_MAX_THRESHOLD, the wireless communication device can consider all received packets before the current packet as "buffered packets" (and can consider the current packet and all received packets after the current packet as "new packets"), and can stop tracking packet arrival timestamps (and continue counting incoming received packets).

[0193] The latency estimator can stop tracking new buffered packets based on the wireless communication device entering a PS (e.g., transmitting based on PM=1). The latency estimator can calculate sleep time and "buffered" packet latency, where sleep time = MIN (the duration between the previous PM=1 and the current PM=0, or the duration between DTIM with TIM settings and PM=0), and buffered packet latency = sleep time divided by 2 (e.g., sleep time / 2). The latency estimator can calculate "new" packet latency, compute latency estimates, and store latency estimates per ITO-SPP (e.g., per ITO-SPP value pair). Some example latency estimator configuration tables are illustrated below.

[0194]

[0195]

[0196]

[0197]

[0198]

[0199] In some examples, the latency estimation scheme or process can be associated with calculating the time until the first packet is received (the active period, after PM=0) and performing one or more actions based on the calculated time. For example, if this time is less than RBO_MIN_THRESHOLD, it is marked as a "buffered packet". The interval between subsequent received packets can be calculated. If the interval is less than a threshold (RBO_MAX_THRESH), the packet can be marked as a "buffered packet". Otherwise, the wireless communication device can mark the packet as a "new packet". The wireless communication device can calculate the buffered packet latency = (duration from the start of sleep to the 1st Rx) / 2 (such as considering beacon monitoring wake-up). The wireless communication device can calculate the new packet latency = fn(congestion) (such as via a lookup table based on congestion metrics). The wireless communication device can calculate the latency estimate = ((number of buffered packets)). (Buffer packet delay) + (Number of new packets) New packet delay) / (total number of packets). Delay estimation can assume or expect downlink arrivals to be uniformly distributed across sleep durations.

[0200] Furthermore, in some aspects, if a wireless communication device has multiple active traffic flows, the device (via a delay estimator) can track received packets to identify the most delay-sensitive flow. By addressing the most delay-sensitive flow, the device can automatically satisfy delay expectations / constraints associated with other traffic flows. In some instances, where the AP explicitly prioritizes traffic flows and if another traffic flow has relatively close or similar delay targets, the device can support and employ sufficiently separated delay constraints to avoid failing to meet delay expectations. For example, if the delay targets for two traffic flows are 5ms and 10ms respectively, and the AP performs explicit prioritization for the 5ms flow, the client device might see the 5ms target satisfied but the 10ms target violated. Therefore, the client device and the AP can (e.g., via exchanged signaling) coordinate information associated with different traffic flows or different service classes to increase the likelihood of sufficiently separated delay constraints between different traffic flows.

[0201] As described in this paper, a delay estimator can interface with a congestion estimator, making a joint congestion metric estimator understandable as being available in association with the delay estimator. The congestion estimator can provide a congestion estimate (a congestion metric value) and a delay adder associated with the congestion estimate (such as calculations or estimations based on the congestion estimate). Congestion-related aspects of the delay estimator can be associated with calculations and estimations. Regarding estimation, the congestion estimator can operate by observing medium congestion and directed traffic volume to estimate overall congestion. The congestion estimator can obtain a congestion metric value as a function of medium congestion and directed traffic volume. In some aspects, wireless communication devices can compute a congestion metric-based lookup table for each frequency band to account for the unique channel characteristics of each band.

[0202] Regarding accounting, in some aspects, new packets may incur delay adders due to congestion, while buffered packets may not (where received packets delivered within RBO_MIN / MAX_THRESHOLD are marked "buffered," and where RBO_MIN_THRESHOLD / RBO_MAX_THRESHOLD is obtained, extracted, or selected from a (service type / congestion metric) lookup table). The congestion metric-based lookup table format can be associated with inputs to a joint congestion metric estimate and the outputs of per-packet delay and RBO_MAX / MIN_THRESHOLD adders. In some aspects, the wireless communication device can feed (such as input) the lookup table output to a delay estimator, causing the per-packet delay and RBO_MAX / MIN_THRESHOLD adders to the delay of each new packet, and updating RBO_MIN / MAX_THRESHOLD used for new / buffered packet tracking. In some aspects, the congestion metric-based lookup table can be statically configured (e.g., based on offline congestion delay analysis). Additionally or alternatively, the congestion metric-based lookup table can be dynamically configured or signaled. In some respects, the congestion metric-based lookup table may not be chip-specific.

[0203] In some respects, wireless communication devices can tune, update, adjust, refine, or change RBO_MIN_THRESHOLD and RBO_MAX_THRESHOLD based on congestion (congestion metric) and traffic classification. For example, regarding congestion as a function, RBO_MIN(MAX)_THRESHOLD = nominal RBO_MIN(MAX)_THRESHOLD + delay adder as a function of congestion. Such delay adder values ​​can be selected from a delay adder lookup table, which can also be used for "new" packets.

[0204] Furthermore, for example, regarding functions for service classification, wireless communication devices can set nominal RBO_MIN_THRESHOLD and RBO_MAX_THRESHOLD based on the service identifier (TID). For example, RBO_MIN_THRESHOLD = the maximum RBO for the corresponding TID. Additionally or alternatively, RBO_MAX_THRESHOLD = RBO_MIN_THRESHOLD + Delta. Delta can be set to a default value, such as zero, and adjusted upwards. The table below illustrates some examples of congestion and service type / congestion and service type-related thresholds. The added delay can be counted for new packets (such as all new packets) (unbuffered) arriving after an RBO_MAX_THRESHOLD delay. Wireless communication devices can use the table exclusively, or they can use a trend line associated with the table.

[0205]

[0206]

[0207] Figure 23 Example flowchart 2300 is shown to support the selection of power-saving parameters based on a joint evaluation of latency and power consumption at the client device. Flowchart 2300 illustrates an example sequence of estimation, computation, determination, selection, or prediction associated with an RL framework, according to which the RL framework can output indications for at least selected ITO-SPP value pairs, such as based on inputs to the ITO-SPP set and latency constraints associated with the traffic flow (such as latency constraints indicated by a traffic type bucket, to which the traffic flow or the traffic class associated with the traffic flow is mapped). In other words, flowchart 2300 can illustrate a sequence of estimators, algorithms, models, or other software, firmware, or hardware components or functionalities associated with the common output indications for one or more power-saving parameters, such as ITO values, SPP values, and sleep modes.

[0208] The wireless communication device can trigger or initiate flowchart 2300 (and similarly, the RL framework) at decision epoch 2305. Decision epoch 2305 may correspond to the start of a given time period, such as the start of a given time epoch. In some aspects, decision epoch 2305 may correspond to the transmission time of an uplink frame, including PM bits (such as PM=0 bits), transmitted by the wireless communication device. For example, decision epoch 2305 may correspond to an indication from the wireless communication device that the wireless communication device is in a wake-up state, which may be associated with an S2W transition. In some implementations, decision epoch 2305 may be every N S2W instances, where N may be a configurable value. The number of steps may be equal to the number of decision epochs performing ITP-SPP selection, or otherwise associated with it.

[0209] According to the triggering or initiation flowchart 2300, the wireless communication device can calculate, select, determine, ascertain, predict, or otherwise obtain power consumption and latency metrics. For example, the wireless communication device can select power consumption and latency metrics in parallel with an indication that the output wireless communication device is in a wake-up state. In some aspects, the power consumption metric can be a normalized power consumption metric and may be referred to as normalized power (NP) 2310. In some aspects, the latency metric can be a normalized latency metric and may be referred to as normalized latency (NL) 2315. The wireless communication device can calculate NP 2310 as P / P0 (power consumption P divided by power normalization factor P0). In some aspects, P0 (which may be equivalently represented as P0) can be calculated such that:

[0210] P0=

[0211] Wireless communication devices can calculate NL 2315 as [MIN(threshold_value, L est / L Constraint )], where L est It is the estimated average delay added due to one or more power-saving parameters (such as, in other words, an estimate of the delay of a downlink packet for a given action (such as a previous action selected during a previous decision epoch), and L Constraint The target delay is added due to one or more power-saving parameters. In some respects, L est It can be obtained as the output of the delay estimator, and L ConstraintThis can be obtained as a characteristic associated with the service type bucket. In some respects, the wireless communication device can calculate NL 2315 such that NL 2315 is at least threshold_value. threshold_value may alternatively be referred to herein as latency_penalty_lower_bound. In other words, the wireless communication device can set a minimum or lower bound for NL 2315, and in some examples, such a minimum can be set to 0.5 (but other minimums are within the scope of this disclosure). Therefore, the RL algorithm can adjust NL 2315 over time, but may not be able to reduce NL 2315 below the minimum set by the wireless communication device.

[0212] Based on NP 2310 and NL 2315, the wireless communication device can calculate, obtain, determine, select, identify, or otherwise determine a penalty value 2320 (such as a cost value) associated with NP 2310 and NL 2315. Because NP 2310 and NL 2315 may correspond to (or be caused by) a prior selection of one or more power-saving parameters (such as ITO, SPP, DTIM periodicity, or sleep mode), the penalty value 2320 can be understood as being calculated for each, for example, (ITO, SPP+DTIM) pair (at least over time, such as across two or more decision epochs). The wireless communication device can calculate a penalty value P such that P(delay estimate = Lest, energy = P) = α min(threshold_value, L) est / L constraint )+(1-α)P / P0. In other words, P=αNL+(1-αNP). Therefore, α2325 can be understood as a trade-off factor between time delay and time delay.

[0213] In some specific implementations, α2325 can be adaptive online (e.g., instantaneously or dynamically). For example, in some aspects, α2325 can be understood as adaptive α. For instance, a wireless communication device can update α2325 such that... α 2325 can be restricted to the range [0:1]. In some respects, ,in This is the attenuation factor. The wireless communication device can selectively update α2325. For example, the wireless communication device can suppress updating α2325 at some decision epochs and can update α at other decision epochs. For example, the wireless communication device can update α2325 every 5 decision epochs or every 10 decision epochs, etc. The α update interval can be set so that α2325 is updated at fixed intervals. Generally speaking, the wireless communication device can update α2325 every M steps, where M can be configurable. Therefore, every M steps can be understood as or regarded as the α update interval.

[0214] Wireless communication devices can perform an initial exploration of various ITO-SPP value pairs to calculate multiple different penalty values, such as the corresponding penalty value for each unique ITO-SPP value pair. This initial exploration phase may be referred to as a "learning phase / period" and can be triggered (once) for each service type bucket. If any given service type bucket has previously undergone a learning phase, the wireless communication device can guide (save-restore) the previously learned statistics. As part of the initial exploration phase, the wireless communication device can initiate, for example, a cyclic selection for each ITO-SPP combination (such as each ITO-SPP value pair), which can increase the likelihood of covering all potential ITO-SPP combinations during the learning phase. The wireless communication device can update the cost / penalty for each ITO-SPP combination based on the cyclic selection.

[0215] Each service type bucket can store the most recently collected statistics for bootstrapping. For example, during a save-and-restore process, during a service type bucket switch, the wireless communication device can save the statistics collected for the current bucket and restore the statistics for the new bucket. Furthermore, RL parameters (such as α2325, ε, step count, and α-step count) and cost / penalty and latency estimation matrices (per ITO-SPP) can be considered. The statistics for the learning phase are saved and restored to avoid delays in picking power-saving parameters. As part of such an initial learning / exploration phase for an RL framework, this phase may take a time amount proportional to the size of the ITO-SPP combination matrix. Service type bucket switches within the learning phase can also undergo save-and-restore and bootstrap from the last picked value, thus ensuring no repetition of learning loops (or otherwise reducing the likelihood of repetition).

[0216] Following the initial exploration, at each decision epoch and using the probability (1-ε), the wireless communication device can select an action (such as an ITO-SPP value pair) with the smallest (e.g., relatively smallest) penalty value among multiple penalty values ​​known to the wireless communication device (e.g., already calculated or previously). Using the probability ε, the wireless communication device can select a random action (e.g., a random ITO-SPP value pair). In some specific implementations, the wireless communication device can select a random action that is adjacent (e.g., in the vicinity) to the action associated with the relatively smallest penalty value (which can be understood as the "optimal" or "best" action known to the wireless communication device). In other words, the wireless communication device (via the RL algorithm / framework illustrated in flowchart 2300) can select (ITO, SPP) value pairs with the relatively smallest average penalty most of the time (e.g., with a probability (1-ε)) and can explore some nearby (ITO, SPP) value pairs with a relatively small probability ε.

[0217] For example, a wireless communication device can perform an ε check 2335 and select an action (ITO-SPP value pair) based on whether a criterion associated with the ε check is met. If the criterion is met, at 2350, the wireless communication device can perform an exploit 2355 and select an ITO-SPP value pair with the relatively minimum penalty. If the criterion is not met, at 2340, the wireless communication device can perform an exploration 2345 and select an ITO-SPP value pair within the general neighborhood of the ITO-SPP value pair with the relatively minimum penalty. In some aspects, the criterion can be dual and can be associated with a threshold number of exploration steps (min_explore_steps) and a threshold of A_MAX(ε, ε_min). The criterion is met if the total number of actions performed by the wireless communication device (total_num_actions) exceeds the threshold number of exploration steps, and if random ε (rand_eps) is greater than the threshold of A_MAX(ε, ε_min). Otherwise, the criteria may not be met if the total number of actions performed by the wireless communication device is less than the threshold number of exploration steps, or if random ε(rand_eps) is less than the threshold of A_MAX(ε, ε_min).

[0218] After the initial learning / exploration phase, when switching business type buckets, the last selected ITO-SPP is considered the starting point (guided using save-restore). Furthermore, it is expected that after the learning phase, a suitable power-saving parameter (a parameter associated with the minimum penalty value or a parameter in the vicinity of the minimum penalty value) will be selected, and that the phase will begin with such a suitable parameter.

[0219] In some respects, ε can decay with the number of decision epochs until it reaches a minimum. For example, at each decision epoch 2305, the wireless communication device can update ε at 2330. The wireless communication device can update ε based on ε = (ε_taper_duration) ε_min) / ((ε_taper_duration ε_min)+((1-ε_min) The value of ε is updated using (total_num_actions - min_explore_steps). In other words, after the initial exploration phase, the wireless communication device can decay ε based on the current step and β. The wireless communication device can initiate an ε update 2330 at each decision epoch 2305. The wireless communication device can trigger a neighborhood search with a probability equal to ε. The range of the neighborhood search (starting from the relatively lowest penalty ITO-SPP combination) can be referred to as the exploration window, and can be + / -1 from one or both of ITO and SPP, + / -2 from one or both of ITO and SPP, and so on. An increment of + / -N from ITO or SPP can be understood as the ability to select ITO or SPP values ​​that are at most N ITO or SPP away from the ITO or SPP associated with the relatively lowest penalty value, where the ITO and SPP values ​​are ordered in ascending or descending order and include candidate values ​​provided by the service type bucket. Wireless communication devices can trigger exploitation with a probability of (1-ε), and can trigger either exploration or exploitation (such as one or the other, but not both) at each decision epoch based on probability ε.

[0220] Below is an example table illustrating available or possible ITO-SPP pairs. Based on the examples illustrated below, the wireless communication device may have calculated a first penalty value for (ITO=35ms, SPP=20ms), a second penalty value for (ITO=30ms, SPP=45ms), and a third penalty value for (ITO=45ms, SPP=40ms).

[0221]

[0222] Furthermore, in some implementations, wireless communication devices can use the RL framework to select DTIM periodicity and sleep mode. Wireless communication devices can choose a larger DTIM periodicity for latency-tolerant services and a shorter DTIM periodicity for latency-sensitive services. Latency-tolerant services may include service flows associated with, for example, YouTube or web browsing (such as non-game, non-interactive services). Example DTIM periodicities for various service flows (such as application type or service class) are illustrated in the table below.

[0223]

[0224] To select a sleep mode, a wireless communication device can choose between light sleep (LS) and deep sleep (DS) based on minimizing (e.g., reducing) energy under a curve related to sleep duration and transition cost. In some aspects, the wireless communication device can set an SPP threshold to enter light sleep, such that (SPP duration...) LS minimum current) + (LS transition time) LS transition current) = (SPP duration) (DS minimum current) + (DS transition time) (DS transition current). In other words, the threshold "SPP duration" can be set such that SPP duration = [(DS transition time)]. (DS transition current) - (LS transition time) [LS transition current) / (LS minimum current - DS minimum current)]. If the selected SPP value is greater than the SPP duration threshold, the wireless communication device can choose to enter deep sleep. Otherwise, the wireless communication device can enter light sleep.

[0225] In some specific implementations, for latency-tolerant services, wireless communication devices can support SPP suppression in deep sleep mode. For example, video streaming services (such as YouTube) are typically bursty, with long idle periods (approximately hundreds of milliseconds or even seconds) between bursts. For such services, wireless communication devices can introduce or employ an additional set of actions in the RL algorithm, i.e., (SPP > DTIM), which can be targeted at a given ITO value. When this action is invoked during the exploration or exploitation phase (making the selected SPP value greater than DTIM), the wireless communication device can skip SPP and directly enter DTIM sleep after ITO. In some examples, to keep latency penalties manageable for this action, the wireless communication device can set the next wake-up time equal to the next target beacon transmission time (TBTT) for the first sleep cycle after ITO. If there is no data activity after the first sleep cycle, the wireless communication device can (only) use a higher (e.g., longer) DTIM periodicity suggested by the algorithm for subsequent sleep cycles. In other words, a wireless communication device can partially wake up to receive a beacon frame at the next TBTT (because a limited number of components, modules, or functionalities can receive and parse beacon frames while they are awake or active), and if the beacon frame does not indicate the presence of data for the wireless communication device, the wireless communication device can re-enter sleep mode and continue the DTIM interval / cycle.

[0226] In some respects, beyond service classifiers and static lookup tables, wireless communication devices can leverage RL frameworks to support more appropriate on-the-fly learning and reconfiguration to address flow-specific characteristics, as a single configuration or set of power-saving parameters may not be adequately suited for all service flows, even those within the same service class. For example, different applications within the same service class may have different service arrival patterns. Therefore, a set of power-saving parameters (ITO, SPP, and DTIM periodicity) suitable for one service arrival profile may not be suitable for another. Furthermore, even within the same application flow, service arrival patterns can change over time based on user activity. Thus, even for the same average latency constraints, the runtime selection of power-saving parameters (ITO, SPP, and DTIM periodicity) allows for greater flexibility in latency / power tradeoffs.

[0227] Furthermore, differences in AP scheduling / aggregation behavior across vendors and backhaul network quality can lead to variations in service patterns for the same application. Some example implementations involving RL frameworks can enable dynamic adjustment of power-saving parameters over time, resulting in a more suitable power / latency tradeoff compared to attempting to configure a single static setting that will work across all potential profiles. Moreover, even for the same average congestion metric, congestion profiles can vary widely depending on OBSS service patterns. In such examples, the same (congestion metric, service classifier) ​​lookup table may not work appropriately across all such potential congestion profiles. Furthermore, the resulting choices of power penalties and (ITO, SPP) can depend on platform-specific parameters such as S2W and W2S transition currents and durations, transmit / listen currents, DTIM periodicity, etc. Therefore, any static lookup table can be associated with expectations for a large number of platform-specific retunings, potentially leading to widespread variations in at least the power penalty depending on platform parameters.

[0228] Figure 24Example classification 2400 is shown to support the selection of power-saving parameters at the client device based on a joint evaluation of latency and power consumption. Classification 2400 can be associated with classifying, mapping, or categorizing service flows 2410 (such as service types or service classes) to service type buckets 2420 used by RL frameworks (such as using features associated with service type buckets to select one or more power-saving parameters for RL frameworks). Service classifier 2405 service types / classes can be mapped to service type buckets 2420 via service bucket mapping 2415. In some aspects, multiple service classifier service types / classes can be mapped to the same service type bucket 2420. Some example service type buckets 2420 include gaming bucket 2420-a (such as corresponding to gaming service flow 2410-a), video call bucket 2420-b (such as corresponding to video call service flow 2410-b), audio call bucket, streaming bucket, and ULL bucket (which can be used according to WLM instructions). Business type bucket 2420 may contain parameters, which include one or more of the following: the supported ITO-SPP set, latency constraints, DTIM periodicity, and collected statistics (used when switching between buckets).

[0229] Figure 25 A block diagram 2500 shows a first wireless communication device 2520 supporting a service classifier for service-aware Wi-Fi operation. The first wireless communication device 2520 may be as shown in the reference... Figures 1 to 24 Examples of various aspects of the described AP 102. The first wireless communication device 2520 or its various components may be examples of parts for performing various aspects of a service classifier for service-aware Wi-Fi operation as described herein. For example, the first wireless communication device 2520 may include a sampling component 2525, a service pattern detection component 2530, a service classification component 2535, a service type communication component 2540, a scheduling information component 2545, a reclassification component 2550, an AIML model input component 2555, an AIML model output component 2560, a service pattern information component 2565, a service pattern indication component 2570, a service condition component 2575, a power-saving operation component 2580, a model creation component 2585, a model training component 2590, a sample labeling component 2595, a monitoring component 25100, a channel access component 25105, or any combination thereof. Each of these components or its components or sub-components (such as one or more processors, one or more memories) may communicate directly or indirectly with each other (such as via one or more buses).

[0230] Furthermore, various components of the first wireless communication device 2520 may provide parts for performing the methods described herein. In some examples, parts for transmitting and / or receiving may include transceivers and / or antennas of the first wireless communication device 2520. In some examples, parts for outputting or transmitting (such as parts for outputting for transmission) and parts for acquiring (such as parts for acquiring after receiving information from different devices) may include one or more interfaces of the first wireless communication device 2520 to output signals to other components or acquire signals from other components of the first wireless communication device 2520. For example, a processor (of a processing system) may output (such as providing) signals and / or data for transmission to a radio frequency front end via a bus interface. Similarly, a device may not actually receive signals and / or data, but may have an interface (parts for acquiring) for acquiring signals and / or data received from another device. For example, a processor (of a processing system) may acquire (or receive) signals and / or data from a radio frequency front end via a bus interface for reception. In various aspects, the radio frequency front end may include various components, including transmit and receive processors, transmit and receive MIMO processors, modulators, demodulators, etc. Each of the components for detection, classification, communication, creation, training, tagging, reclassification, execution, monitoring, recovery, selection, and / or updating includes the processing system, processor circuitry (including one or more processors), memory circuitry, and / or computer-readable medium of the first wireless communication device 2520.

[0231] The first wireless communication device 2520 can support wireless communication according to the examples disclosed herein. The sampling component 2525 can be configured or configured to obtain a set of multiple samples associated with a set of multiple packets including data. The service pattern detection component 2530 can be configured or configured to detect one or more transmission service patterns associated with the set of multiple packets based on one or more parameters associated with the set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both. The service classification component 2535 can be configured or configured to classify the set of multiple packets according to one or more service types based on one or more transmission service patterns. The service type communication component 2540 can be configured or configured to communicate according to one or more service types.

[0232] In some examples, to support communication based on one or more service types, the scheduling information component 2545 can be configured to, or be configured to, output scheduling information associated with a set of multiple packets, wherein the scheduling information is output based on a channel access scheme based on one or more service types.

[0233] In some examples, the model creation component 2585 can be configured or configured to create a model to detect one or more transmission service patterns. In some examples, the model training component 2590 can be configured or configured to train a model based on a stream classification service request. In some examples, the sample labeling component 2595 can be configured or configured to detect whether one or more portions of a set of multiple samples correspond to one or more transmission service types. In some examples, the sample labeling component 2595 can be configured or configured to label a set of multiple samples as a set of multiple training samples for training the model, or to label a first portion of a set of multiple samples as a set of multiple training samples, wherein the first portion is not detected to correspond to a corresponding transmission service type, and wherein labeling the first portion is based on a second portion of the set of multiple samples corresponding to the transmission service type associated with the first portion. In some examples, the model training component 2590 can be configured or configured to train a model using a set of multiple training samples based on labeling a set of multiple samples as a set of multiple training samples or labeling a first portion of a set of multiple samples as a set of multiple training samples.

[0234] In some examples, the channel access component 25105 can be configured or configured to obtain one or more channel access triggers associated with one or more channel access schemes, wherein the one or more channel access schemes include a channel access scheme in which at least one of the following is obtained: obtaining one or more channel access triggers is based on at least one of one or more service types or compliance with a policy, or outputting scheduling information further based on one or more channel access triggers.

[0235] In some examples, the channel access component 25105 can be configured or configured to output one or more channel access triggers associated with one or more channel access schemes, the one or more channel access schemes including channel access schemes, the output being based on one or more service types, wherein the output scheduling information is further based on one or more channel access triggers.

[0236] In some examples, in order to support the detection of one or more transmission service modes, the service mode detection component 2530 can be configured to or be configured to detect real-time services associated with a first window of a set of multiple samples or streaming services associated with a second window of a set of multiple samples.

[0237] In some examples, to support the classification of a set of multiple packets, the reclassification component 2550 can be configured or be configured to reclassify a set of multiple packets based on a send service type confidence level that is less than or equal to a threshold confidence level.

[0238] In some examples, to support the detection of one or more transmission service patterns, the AIML model input component 2555 can be configured or configured to output one or more parameters associated with a set of multiple samples to the artificial intelligence model or machine learning model, wherein the one or more parameters include one or more quality of service requirements. In some examples, to support the detection of one or more transmission service patterns, the AIML model output component 2560 can be configured or configured to obtain one or more transmission service patterns from the artificial intelligence model or machine learning model.

[0239] In some examples, the service mode information component 2565 can be configured or configured to obtain service mode information associated with one or more other access points, wherein the detection of one or more transmission service modes is further based on the service mode information. In some examples, the service mode indication component 2570 can be configured or configured to convey an indication of one or more detected transmission service modes.

[0240] In some examples, the service condition component 2575 can be configured or be configured to obtain one or more service activities, one or more service loads, or any combination thereof based on one or more transmission service modes, wherein each of the one or more service types, one or more service activities, and one or more service loads is associated with a corresponding service flow in a set of multiple service flows, wherein the set of multiple service flows is associated with a set of multiple samples, wherein communication includes performing power saving operations based on one or more service types, one or more service activities, one or more service loads, or any combination thereof.

[0241] In some examples, the service condition component 2575 can be configured or configured to obtain one or more second service types, one or more second service activities, one or more second service loads, or any combination thereof. In some examples, the power saving operation component 2580 can be configured or configured to perform a second power saving operation based on one or more second service types, one or more second service activities, one or more second service loads, or any combination thereof.

[0242] In some examples, the monitoring component 25100 can be configured or configured to monitor a first set of multiple service flows associated with a first transmission service type according to a first periodicity. In some examples, the monitoring component 25100 can be configured or configured to monitor a second set of multiple service flows associated with a second transmission service type according to a second periodicity. In some examples, the monitoring component 25100 can be configured or configured to monitor a third set of multiple service flows associated with a third transmission service type according to a third periodicity, wherein the set of multiple service flows includes a first set of multiple service flows, a second set of multiple service flows, and a third set of multiple service flows. In some examples, the monitoring component 25100 can be configured or configured to implement one or more of the first, second, and third transmission service types without reclassifying the set of multiple service flows, the implementation operating according to one or more activities associated with the first, second, or third set of multiple service flows and according to power saving operations at the wireless node.

[0243] In some examples, to support the execution of power-saving operations, the power-saving operation component 2580 can be configured or configured to perform power-saving operations based on the fulfillment of one or more conditions, wherein the one or more conditions include at least one of the following: the presence of a video streaming service type, the absence of a latency-sensitive or real-time service type, or the sum of one or more second service loads associated with a background service type is less than or equal to a threshold service load, wherein the one or more service loads include at least one or more second service loads.

[0244] In some examples, the monitoring component 25100 can be configured to, or be configured to, periodically monitor the sum of one or more second service loads associated with a back-end service type.

[0245] Figure 26 A block diagram 2600 shows a second wireless communication device 2620 supporting a service classifier for service-aware Wi-Fi operation. The second wireless communication device 2620 can be as shown in the reference... Figures 1 to 24Examples of various aspects of the described STA 104. The second wireless communication device 2620 or its various components may be examples of parts for performing various aspects of a service classifier for service-aware Wi-Fi operation as described herein. For example, the second wireless communication device 2620 may include a sampling component 2625, a service pattern detection component 2630, a service classification component 2635, a service type communication component 2640, a service flow component 2645, a power management component 2650, a communication component 2655, a scheduling information component 2660, a reclassification component 2665, an AIML model input component 2670, an AIML model output component 2675, a service pattern information component 2680, a service pattern indication component 2685, a service condition component 2690, a power saving operation component 2695, a model creation component 26100, a model training component 26105, a sample labeling component 26110, a monitoring component 26115, a channel access component 26125, or any combination thereof. Each of these components, or its components or sub-components (such as one or more processors, one or more memories), can communicate with each other directly or indirectly (such as via one or more buses).

[0246] The second wireless communication device 2620 can support wireless communication according to the examples disclosed herein. The sampling component 2625 can be configured or configured to obtain a set of multiple samples associated with a set of multiple packets including data. The service pattern detection component 2630 can be configured or configured to detect one or more transmission service patterns associated with the set of multiple packets based on one or more parameters associated with the set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both. The service classification component 2635 can be configured or configured to classify the set of multiple packets according to one or more service types based on one or more transmission service patterns. The service type communication component 2640 can be configured or configured to communicate according to one or more service types.

[0247] In some examples, to support communication based on one or more service types, the scheduling information component 2660 can be configured to, or be configured to, output scheduling information associated with a set of multiple packets, wherein the scheduling information is output based on a channel access scheme based on one or more service types.

[0248] In some examples, the model creation component 26100 can be configured to or be configured to create a model to detect one or more transmission service modes. In some examples, the model training component 26105 can be configured to or be configured to train a model based on a stream classification service request. In some examples, the sample labeling component 26110 can be configured to or be configured to detect whether one or more portions of a set of multiple samples correspond to one or more transmission service types. In some examples, the sample labeling component 26110 can be configured to or be configured to label a set of multiple samples as a set of multiple training samples for training the model, or to label a first portion of a set of multiple samples as a set of multiple training samples, wherein the first portion is not detected to correspond to a corresponding transmission service type, and wherein labeling the first portion is based on a second portion of the set of multiple samples corresponding to the transmission service type associated with the first portion. In some examples, the model training component 26105 can be configured to or be configured to train a model using a set of multiple training samples based on labeling a set of multiple samples as a set of multiple training samples or labeling a first portion of a set of multiple samples as a set of multiple training samples.

[0249] In some examples, channel access component 26125 can be configured or configured to acquire one or more channel access triggers associated with one or more channel access schemes, wherein the one or more channel access schemes include channel access schemes, wherein at least one of the following is true: acquiring one or more channel access triggers is based on at least one of one or more service types or compliance with a policy, or outputting scheduling information further based on one or more channel access triggers. In some examples, channel access component 26125 can be configured or configured to output one or more channel access triggers associated with one or more channel access schemes, wherein the one or more channel access schemes include channel access schemes, and the output is based on one or more service types, wherein the output scheduling information is further based on one or more channel access triggers.

[0250] In some examples, to support the detection of one or more transmission service patterns, the service pattern detection component 2630 can be configured or configured to detect real-time services associated with a first window of a set of multiple samples or streaming services associated with a second window of a set of multiple samples that is longer than the first window. In some examples, to support the classification of a set of multiple packets, the reclassification component 2665 can be configured or configured to reclassify the set of multiple packets based on a transmission service type confidence level that is less than or equal to a threshold confidence level.

[0251] In some examples, to support the detection of one or more transmission service patterns, the AIML model input component 2670 can be configured or configured to output one or more parameters associated with a set of multiple samples to the artificial intelligence model or machine learning model, wherein the one or more parameters include one or more quality of service requirements. In some examples, to support the detection of one or more transmission service patterns, the AIML model output component 2675 can be configured or configured to obtain one or more transmission service patterns from the artificial intelligence model or machine learning model.

[0252] In some examples, the service mode information component 2680 can be configured or configured to obtain service mode information associated with one or more other access points, wherein the detection of one or more transmission service modes is further based on the service mode information. In some examples, the service mode indication component 2685 can be configured or configured to convey an indication of one or more detected transmission service modes.

[0253] In some examples, the service condition component 2690 can be configured or be configured to obtain one or more service activities, one or more service loads, or any combination thereof based on one or more transmission service modes, wherein each of the one or more service types, one or more service activities, and one or more service loads is associated with a corresponding service flow in a set of multiple service flows, wherein the set of multiple service flows is associated with a set of multiple samples, wherein communication includes performing power saving operations based on one or more service types, one or more service activities, one or more service loads, or any combination thereof.

[0254] In some examples, the service condition component 2690 can be configured or configured to obtain one or more second service types, one or more second service activities, one or more second service loads, or any combination thereof. In some examples, the power saving operation component 2695 can be configured or configured to perform a second power saving operation based on one or more second service types, one or more second service activities, one or more second service loads, or any combination thereof.

[0255] In some examples, monitoring component 26115 can be configured or configured to monitor a first set of multiple service flows associated with a first transmission service type according to a first periodicity. In some examples, monitoring component 26115 can be configured or configured to monitor a second set of multiple service flows associated with a second transmission service type according to a second periodicity. In some examples, monitoring component 26115 can be configured or configured to monitor a third set of multiple service flows associated with a third transmission service type according to a third periodicity, wherein the set of multiple service flows includes a first set of multiple service flows, a second set of multiple service flows, and a third set of multiple service flows. In some examples, monitoring component 26115 can be configured or configured to implement one or more of the first, second, and third transmission service types without reclassifying the set of multiple service flows, the implementation operating according to one or more activities associated with the first, second, or third set of multiple service flows and according to power saving operations at the wireless node.

[0256] In some examples, to support the execution of power-saving operations, the power-saving operation component 2695 can be configured or configured to perform power-saving operations based on the fulfillment of one or more conditions, wherein the one or more conditions include at least one of the following: the presence of a video streaming service type, the absence of a latency-sensitive or real-time service type, or the sum of one or more second service loads associated with a background service type is less than or equal to a threshold service load, wherein the one or more service loads include at least one or more second service loads.

[0257] In some examples, the monitoring component 26115 can be configured to, or be configured to, periodically monitor the sum of one or more second service loads associated with a back-end service type.

[0258] Additionally or alternatively, the second wireless communication device 2620 may support wireless communication according to the examples disclosed herein. A traffic flow component 2645 can be configured or is configured to obtain information associated with traffic flows to the wireless node. In some examples, a traffic classification component 2635 can be configured or is configured to obtain indications of a first set of values ​​associated with inactivity timeouts and a second set of values ​​associated with polling periods based on the classification of the traffic flows. A power management component 2650 can be configured or is configured to select a first value from the first set of values ​​and a first value from the second set of values ​​at the beginning of the first duration based on latency and power consumption metrics both associated with the second duration. A communication component 2655 can be configured or is configured to communicate during the first duration based on a first value from at least the first set of values ​​or a first value from the second set of values.

[0259] In some examples, the power management component 2650 can be configured or configured to output a frame including an indication that the wireless node is in a wake-up state, wherein selecting a first value from a first set of values ​​and selecting a first value from a second set of values ​​are performed in parallel with the output frame. In some examples, the transmission time of the frame corresponds to the start of the first duration.

[0260] In some examples, the service classification component 2635 can be configured or configured to obtain an indication of the DTIM periodicity associated with the service flow based on the classification of the service flow, wherein communication during a first duration is further based on the DTIM periodicity. In some examples, the service classification component 2635 can be configured or configured to obtain an indication of the latency constraint associated with the service flow based on the classification of the service flow, wherein a latency metric is associated with a latency constraint.

[0261] In some examples, the service classification component 2635 can be configured or be configured to acquire a set of multiple frames during a sleep state associated with a previous polling cycle within a second duration, wherein at least one of the following is true: the latency metric is a normalized latency metric associated with at least one of estimated latency or latency constraints, or the estimated latency is associated with at least one of a set of multiple frames acquired during the sleep state or a congestion factor.

[0262] In some examples, the latency metric is equal to or greater than a threshold. In some examples, the power consumption metric is a normalized power consumption metric associated with at least one of the estimated power or a power normalization factor. In some examples, the estimated power corresponds to the power consumption associated with at least one of the previous inactivity timeout value or the previous speculative polling cycle value for the second duration.

[0263] In some examples, the power management component 2650 can be configured or configured to select a sleep mode based on a first value from a second set of values, wherein communication is performed further according to the sleep mode during a first duration. In some examples, to support sleep mode selection, the power management component 2650 can be configured or configured to select a first sleep mode based on a first value from the second set of values ​​being less than or equal to a threshold speculative polling period value. In some examples, to support sleep mode selection, the power management component 2650 can be configured or configured to select a second sleep mode based on a first value from the second set of values ​​being greater than or equal to a threshold speculative polling period value, wherein the second sleep mode is longer in duration than the first sleep mode.

[0264] In some examples, the power management component 2650 can be configured or be configured to enter a sleep state until at least the next TBTT based on a first value from a second set of values ​​being greater than or equal to the DTIM interval, or enter a partial wake-up state to obtain a beacon frame at the next TBTT, or re-enter a sleep state and continue for the DTIM interval based on the lack of indication of data activity of the wireless node in the beacon frame.

[0265] In some examples, a first value is selected from a first set of values, and a second value is selected from a second set of values, based on penalty values ​​based on latency and power consumption metrics. In some examples, the primary value is equal to the first product of the latency metric and the α value. In some examples, the secondary value is equal to the second product of the power consumption metric and (1-α value).

[0266] In some examples, the power management component 2650 can be configured or be configured to update the α value from a first value to a second value, wherein the difference between the first value and the second value is associated with the difference between the estimated latency and the latency constraint associated with the traffic flow, wherein the estimated latency is associated with a set of multiple frames and a congestion factor obtained during a sleep state, which is associated with a previously speculative polling period value for a second duration.

[0267] In some examples, the power management component 2650 can be configured or configured to obtain a set of multiple penalty values ​​based on a set of multiple latency and power consumption metrics associated with a set of multiple durations, the set of multiple latency and power consumption metrics including latency and power consumption metrics, wherein different value pairs from a first set of values ​​and a second set of values ​​are associated with different penalty values ​​in the set of multiple penalty values.

[0268] In some examples, a first pair of first values ​​from a first set of values ​​and a first value from a second set of values ​​are associated with the lowest penalty value in a set of multiple penalty values. In some examples, a second pair of second values ​​from a first set of values ​​and a second value from a second set of values ​​are associated with the lowest penalty value in a set of multiple penalty values. In some examples, at least one of a first value from a first set of values ​​or a second value from a second set of values ​​is close to at least one of a second value from a first set of values ​​or a second value from a second set of values.

[0269] In some examples, to support communication based on a first value from at least a first set of values ​​or a first value from a second set of values, the communication component 2655 can be configured or configured to output a first frame indicating that the wireless node is in a wake-up state, wherein the first frame is output based on the first value from the second set of values. In some examples, to support communication based on a first value from at least a first set of values ​​or a first value from a second set of values, the communication component 2655 can be configured or configured to output a second frame indicating that the wireless node is in a sleep state, wherein the second frame is output based on the first value from the first set of values. In some examples, the second duration immediately precedes the first duration.

[0270] Figure 27 A flowchart illustrating method 2700 for supporting a service classifier for service-aware Wi-Fi operation is shown. Operation of method 2700 may be implemented by a first wireless communication device (such as AP 102) or a second wireless communication device (such as STA 104) or components thereof, as described herein. For example, operation of method 2700 may be implemented by, as referenced... Figures 1 to 25 The described AP 102 or as referenced Figures 1 to 24 and Figure 26 The STA 104 described herein is used for execution. In some examples, the first or second wireless communication device may execute a set of instructions to control the functional elements of the first or second wireless communication device to perform the described functions. Additionally or alternatively, the first or second wireless communication device may use dedicated hardware to perform aspects of the described functions.

[0271] At 2705, the method may include obtaining a set of multiple samples associated with a set of multiple groups including data. The operation of 2705 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2705 may be derived from, as referenced... Figure 25 and Figure 26 The sampling component 2525 or sampling component 2625 described herein shall be used to perform this action.

[0272] At 2705, the method may include obtaining a set of multiple samples associated with a set of multiple groups including data. The operation of 2705 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2705 may be derived from, as referenced... Figure 25 and Figure 26 The sampling component 2525 or sampling component 2625 described herein shall be used to perform this action.

[0273] At 2710, the method may include detecting one or more transmission service patterns associated with a set of multiple packets based on one or more parameters associated with a set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both. The operation of 2710 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2710 may be provided by reference to [reference needed]. Figure 25 and Figure 26 The described business pattern detection component 2530 or business pattern detection component 2630 shall be used to perform this.

[0274] At 2715, the method may include classifying a set of multiple packets according to one or more service types based on one or more transmission service modes. The operation of 2715 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2715 may be derived from, as referenced... Figure 25 and Figure 26 The described business category component 2535 or business category component 2635 is used to execute.

[0275] At 2720, the method may include communicating according to one or more service types. The operation of 2720 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2720 may be derived from, as referenced... Figure 25 and Figure 26 The described service type communication component 2540 or service type communication component 2640 shall be used to perform this.

[0276] Figure 28 A flowchart illustrating method 2800 for supporting a service classifier for service-aware Wi-Fi operation is shown. Operation of method 2800 may be implemented by a first wireless communication device (such as AP 102) or a second wireless communication device (such as STA 104) or components thereof, as described herein. For example, operation of method 2800 may be implemented by, as referenced... Figures 1 to 25 The described AP 102 or as referenced Figures 1 to 24 and Figure 26 The STA 104 described herein is used for execution. In some examples, the first or second wireless communication device may execute a set of instructions to control the functional elements of the first or second wireless communication device to perform the described functions. Additionally or alternatively, the first or second wireless communication device may use dedicated hardware to perform aspects of the described functions.

[0277] At 2805, the method may include obtaining a set of multiple samples associated with a set of multiple groups including data. The operation at 2805 can be performed according to the examples disclosed herein. In some examples, aspects of the operation at 2805 may be derived from, as referenced... Figure 25 and Figure 26 The sampling component 2525 or sampling component 2625 described herein shall be used to perform this action.

[0278] At 2810, the method may include detecting one or more transmission service patterns associated with a set of multiple packets based on one or more parameters associated with a set of multiple samples, one or more parameters associated with a previous set of multiple samples, or both. The operation of 2810 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2810 may be provided by reference to [reference needed]. Figure 25 and Figure 26 The described business pattern detection component 2530 or business pattern detection component 2630 shall be used to perform this.

[0279] At 2815, the method may include classifying a set of multiple packets according to one or more service types based on one or more transmission service modes. The operation of 2815 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2815 may be derived from, as referenced... Figure 25 and Figure 26 The described business category component 2535 or business category component 2635 is used to execute.

[0280] At 2820, the method may include communicating according to one or more service types. The operation of 2820 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2820 may be provided by reference to [reference needed]. Figure 25 and Figure 26 The described service type communication component 2540 or service type communication component 2640 shall be used to perform this.

[0281] At 2825, the method may include obtaining one or more service activities, one or more service loads, or any combination thereof based on one or more transmission service modes, wherein each of the one or more service types, one or more service activities, and one or more service loads is associated with a corresponding service flow in a set of multiple service flows, wherein the set of multiple service flows is associated with a set of multiple samples, and wherein communication includes performing power-saving operations based on one or more service types, one or more service activities, one or more service loads, or any combination thereof. The operation of 2825 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2825 may be derived from, as referenced... Figure 25 and Figure 26 The described business condition component 2575 or business condition component 2690 shall be used to execute.

[0282] Figure 29A flowchart illustrating method 2900 for supporting a service classifier for service-aware Wi-Fi operation is shown. Operation of method 2900 may be implemented by a second wireless communication device (such as STA 104) or components thereof, as described herein. For example, operation of method 2900 may be implemented by, as referenced... Figures 1 to 24 and Figure 26 The second wireless communication device described herein performs the function. In some examples, the second wireless communication device may execute a set of instructions to control the functional elements of the second wireless communication device to perform the described function. Additionally or alternatively, the second wireless communication device may use dedicated hardware to perform aspects of the described function.

[0283] At 2905, the method may include obtaining information associated with the traffic flow to the wireless node. The operation of 2905 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2905 may be derived from, as referenced... Figure 26 The described business flow component 2645 is used to execute it.

[0284] At 2910, the method may include obtaining indications of a first set of values ​​associated with inactivity timeouts and a second set of values ​​associated with polling periods, based on the classification of the business flow. The operation of 2910 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2910 may be derived from, as referenced... Figure 26 The described business category component 2635 is used for execution.

[0285] At 2915, the method may include selecting a first value from a first set of values ​​and selecting a first value from a second set of values ​​at the beginning of the first duration based on a delay metric and a power consumption metric both associated with the second duration. The operation of 2915 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2915 may be derived from, as referenced... Figure 26 The power management component 2650 described is used to perform this.

[0286] At 2920, the method may include communicating during a first duration based on a first value from at least a first set of values ​​or a first value from a second set of values. The operation of 2920 can be performed according to the examples disclosed herein. In some examples, aspects of the operation of 2920 may be derived from, as referenced... Figure 26 The described communication component 2655 is used to perform this.

[0287] Specific implementation examples are described in the following numbered clauses:

[0288] Aspect 1: A method for wireless communication at a wireless node, the method comprising: obtaining a plurality of samples associated with a plurality of packets including data; detecting one or more transmission service patterns associated with the plurality of packets based at least in part on one or more parameters associated with the plurality of samples, one or more parameters associated with a previous plurality of samples, or both; classifying the plurality of packets according to one or more service types based at least in part on the one or more transmission service patterns; and communicating according to the one or more service types.

[0289] Aspect 2: According to the method of aspect 1, wherein communicating according to the one or more service types includes: outputting scheduling information associated with the plurality of packets, wherein the scheduling information is output according to a channel access scheme based at least in part on the one or more service types.

[0290] Aspect 3: The method according to any one of Aspects 1 to 2, the method further comprising: creating a model to detect the one or more transmission service patterns; training the model at least in part based on a stream classification service request; detecting whether one or more portions of the plurality of samples correspond to one or more transmission service types; labeling the plurality of samples as a plurality of training samples for training the model or labeling a first portion of the plurality of samples as the plurality of training samples, wherein the first portion is not detected as corresponding to a corresponding transmission service type, and wherein labeling the first portion is at least in part based on a second portion of the plurality of samples corresponding to a transmission service type associated with the first portion; and training the model using the plurality of training samples based on labeling the plurality of samples as the plurality of training samples or labeling the first portion of the plurality of samples as the plurality of training samples.

[0291] Aspect 4: The method according to any one of Aspects 2 to 3, the method further comprising: obtaining one or more channel access triggers associated with one or more channel access schemes, the one or more channel access schemes including the channel access scheme, wherein at least one of the following: obtaining the one or more channel access triggers is at least partially based on at least one of the one or more service types or compliance with a policy; or outputting the scheduling information further at least partially based on the one or more channel access triggers.

[0292] Aspect 5: The method according to any one of Aspects 2 to 4, the method further comprising: outputting one or more channel access triggers associated with one or more channel access schemes, the one or more channel access schemes including the channel access scheme, the output being at least partially based on the one or more service types, wherein the output of the scheduling information is further at least partially based on the one or more channel access triggers.

[0293] Aspect 6: The method according to any one of Aspects 1 to 5, wherein detecting the one or more transmission service modes comprises: detecting real-time services associated with a first window of the plurality of samples or streaming services associated with a second window of the plurality of samples that is longer than the first window.

[0294] Aspect 7: The method according to any one of Aspects 1 to 6, wherein classifying the plurality of packets includes: reclassifying the plurality of packets at least in part based on a confidence level of the transmission service type being less than or equal to a threshold confidence level.

[0295] Aspect 8: The method according to any one of Aspects 1 to 7, wherein detecting the one or more transmission service patterns comprises: outputting the one or more parameters associated with the plurality of samples to an artificial intelligence model or a machine learning model, wherein the one or more parameters include one or more quality of service requirements; and obtaining the one or more transmission service patterns from the artificial intelligence model or machine learning model.

[0296] Aspect 9: The method according to any one of Aspects 1 to 8, the method further comprising: obtaining service mode information associated with one or more other access points, wherein the detection of the one or more transmission service modes is further based at least in part on the service mode information; and conveying an indication of one or more detected transmission service modes.

[0297] Aspect 10: The method according to any one of Aspects 1 to 9, further comprising: obtaining one or more service activities, one or more service loads, or any combination thereof, at least in part based on the one or more transmission service modes, wherein the one or more service types, the one or more service activities, and the one or more service loads are each associated with a corresponding service flow in a plurality of service flows, wherein the plurality of service flows are associated with the plurality of samples, wherein: the communication includes performing power saving operations based on the one or more service types, the one or more service activities, the one or more service loads, or any combination thereof.

[0298] Aspect 11: The method according to aspect 10 further includes: obtaining one or more second service types, one or more second service activities, one or more second service loads, or any combination thereof; and performing a second power saving operation based on the one or more second service types, the one or more second service activities, the one or more second service loads, or any combination thereof.

[0299] Aspect 12: The method according to aspect 11, further comprising: monitoring a first plurality of traffic flows associated with a first transmission service type according to a first periodicity; monitoring a second plurality of traffic flows associated with a second transmission service type according to a second periodicity; monitoring a third plurality of traffic flows associated with a third transmission service type according to a third periodicity, wherein the plurality of traffic flows includes the first plurality of traffic flows, the second plurality of traffic flows, and the third plurality of traffic flows; and implementing one or more of the first transmission service type, the second transmission service type, and the third transmission service type without reclassifying the plurality of traffic flows, the implementation being based on one or more activities associated with the first plurality of traffic flows, the second plurality of traffic flows, or the third plurality of traffic flows and based on power saving operations at the wireless node.

[0300] Aspect 13: The method according to any one of Aspects 10 to 12, wherein performing the power saving operation comprises: performing the power saving operation based on satisfying one or more conditions, wherein the one or more conditions include at least one of the following: the presence of a video streaming service type; the absence of a latency-sensitive or real-time service type; or the sum of one or more second service loads associated with a background service type is less than or equal to a threshold service load, wherein the one or more service loads include at least the one or more second service loads.

[0301] Aspect 14: According to the method of aspect 13, the method further includes: periodically monitoring the sum of the one or more second service loads associated with the back-end service type.

[0302] Aspect 15: A method for wireless communication at a wireless node, the method comprising: obtaining information associated with a traffic flow to the wireless node; obtaining indications of a first set of values ​​associated with inactivity timeout and a second set of values ​​associated with a polling period based on a classification of the traffic flow; selecting a first value from the first set of values ​​and a first value from the second set of values ​​at the beginning of a first duration based on a latency metric and a power consumption metric both associated with a second duration; and communicating during the first duration based on at least one of the first value from the first set of values ​​or the first value from the second set of values.

[0303] Aspect 16: According to the method of aspect 15, the method further includes: outputting a frame including an indication that the wireless node is in a wake-up state, wherein selecting the first value from the first set of values ​​and selecting the first value from the second set of values ​​are performed in parallel with outputting the frame.

[0304] Aspect 17: According to the method of aspect 16, wherein the transmission time of the frame corresponds to the start of the first duration.

[0305] Aspect 18: The method according to any one of aspects 15 to 17, the method further comprising: obtaining an indication of DTIM periodicity associated with the service flow based on the classification of the service flow, wherein communication during the first duration is further based on the DTIM periodicity.

[0306] Aspect 19: The method according to any one of Aspects 15 to 18, the method further comprising: obtaining an indication of a latency constraint associated with the service flow based on the classification of the service flow, wherein the latency metric is associated with the latency constraint.

[0307] Aspect 20: The method according to aspect 19, the method further comprising: obtaining a plurality of frames during a sleep state associated with a previous polling cycle within the second duration, wherein at least one of the following: the latency metric is a normalized latency metric associated with at least one of an estimated latency or a latency constraint, or the estimated latency is associated with at least one of the plurality of frames or a congestion factor obtained during the sleep state.

[0308] Aspect 21: According to the method of aspect 20, the time delay metric is equal to or greater than a threshold.

[0309] Aspect 22: The method according to any one of Aspects 15 to 21, wherein at least one of the following is true: the power consumption metric is a normalized power consumption metric associated with at least one of estimated power or power normalization factor, or the estimated power corresponds to power consumption associated with at least one of a previous inactivity timeout value or a previous speculative polling cycle value for the second duration.

[0310] Aspect 23: The method according to any one of aspects 15 to 22, the method further comprising: selecting a sleep mode based on the first value from the second set of values, wherein communication is further performed according to the sleep mode during the first duration.

[0311] Aspect 24: According to the method of aspect 23, selecting the sleep mode includes: selecting a first sleep mode based on the first value from the second set of values ​​being less than or equal to a threshold speculative polling period value; or selecting a second sleep mode based on the first value from the second set of values ​​being greater than or equal to the threshold speculative polling period value, wherein the second sleep mode is longer in duration than the first sleep mode.

[0312] Aspect 25: The method according to any one of aspects 15 to 24, the method further comprising: entering a sleep state until at least the next TBTT based on the first value from the second set of values ​​being greater than or equal to the DTIM interval, or re-entering the sleep state and continuing the DTIM interval based on the lack of indication of data activity of the radio node in the beacon frame.

[0313] Aspect 26: The method according to any one of Aspects 15 to 25, wherein the selection of the first value includes selecting the first value based on a penalty value based on the latency metric and the power consumption metric.

[0314] Aspect 27: According to the method of aspect 26, wherein the penalty value is associated with the sum of a primary value and a secondary value, wherein at least one of the following is true: the primary value is equal to a first product of the delay metric and the α value, or the secondary value is equal to a second product of the power consumption metric and (1 - the α value).

[0315] Aspect 28: The method according to aspect 27 further includes: updating the α value from a first value to a second value, wherein the difference between the first value and the second value is associated with the difference between an estimated latency and a latency constraint associated with the traffic flow, wherein the estimated latency is associated with a plurality of frames and a congestion factor obtained during a sleep state, the sleep state being associated with a previously speculative polling period value for the second duration.

[0316] Aspect 29: The method according to any one of Aspects 15 to 28, the method further comprising: obtaining a plurality of penalty values ​​based on a plurality of latency metrics and power consumption metrics associated with a plurality of durations, the plurality of latency metrics and power consumption metrics including the latency metrics and the power consumption metrics, wherein different value pairs from the first set of values ​​and the second set of values ​​are associated with different penalty values ​​among the plurality of penalty values.

[0317] Aspect 30: According to the method of aspect 29, a first pair of the first value from the first set of values ​​and the first value from the second set of values ​​are associated with the lowest penalty value among the plurality of penalty values.

[0318] Aspect 31: The method according to any one of Aspects 29 to 30, wherein at least one of the following: a second pair of a second value from the first set of values ​​and a second value from the second set of values ​​is associated with the lowest penalty value among the plurality of penalty values, or at least one of the first value from the first set of values ​​or the second value from the second set of values ​​is close to at least one of the second value from the first set of values ​​or the second value from the second set of values.

[0319] Aspect 32: The method according to any one of aspects 15 to 31, wherein communicating based on the first value from at least the first set of values ​​or the first value from the second set of values ​​comprises: outputting a first frame indicating that the wireless node is in an awake state, wherein the first frame is output based on the first value from the second set of values; or outputting a second frame indicating that the wireless node is in a sleep state, wherein the second frame is output based at least in part on the first value from the first set of values.

[0320] Aspect 33: The method according to any one of aspects 15 to 32, wherein the second duration immediately precedes the first duration in time.

[0321] Aspect 34: A wireless node comprising at least one transceiver and a processing system, the processing system comprising processor circuitry and memory circuitry for storing code, the processing system being configured to cause the wireless node to perform a method according to any one of aspects 1 to 14, wherein the at least one transceiver is configured to receive a plurality of samples.

[0322] Aspect 35: An apparatus for wireless communication, the apparatus comprising a processing system including processor circuitry and memory circuitry storing code, the processing system being configured to cause the apparatus to perform a method according to any one of aspects 1 to 14.

[0323] Aspect 36: An apparatus for wireless communication, the apparatus comprising at least one component for performing the method according to any one of aspects 1 to 14.

[0324] Aspect 37: A non-transitory computer-readable medium storing code for wireless communication, said code including instructions executable by one or more processors to perform the method according to any one of aspects 1 to 14.

[0325] Aspect 38: A wireless node comprising: at least one transceiver; and a processing system including processing circuitry and memory circuitry for storing code, the processing system being configured to cause the wireless node to perform a method according to any one of aspects 15 to 33, wherein the at least one transceiver is configured to receive information and receive instructions.

[0326] Aspect 39: An apparatus for wireless communication, the apparatus comprising a processing system including processor circuitry and memory circuitry storing code, the processing system being configured to cause the apparatus to perform a method according to any one of aspects 15 to 33.

[0327] Aspect 40: An apparatus for wireless communication, the apparatus comprising at least one component for performing the method according to any one of aspects 15 to 33.

[0328] Aspect 41: A non-transitory computer-readable medium storing code for wireless communication, said code including instructions executable by one or more processors to perform a method according to any one of aspects 15 to 33.

[0329] As used herein, the term "determine" encompasses a wide variety of actions, and therefore, "determine" can include calculation, computation, processing, derivation, estimation, investigation, searching (such as by searching in a table, database, or other data structure), reasoning, probing, or measurement, among other possibilities. Furthermore, "determine" can include receiving (such as receiving information), accessing (such as accessing data stored in memory), or sending (such as sending information), among other possibilities. Additionally, "determine" can include parsing, selecting, obtaining, choosing, building, and other similar actions.

[0330] As used herein, the phrase “at least one of” or “one or more of” refers to any combination of these items, including a single member. For example, “at least one of a, b, or c” is intended to cover: a, b, c, ab, ac, bc, and abc. As used herein, “or” is intended to be interpreted in an inclusive sense unless otherwise expressly indicated. For example, “a or b” may include only a, only b, or a combination of a and b. Furthermore, as used herein, the phrase referring to “a” element means one or more of such elements that act individually or collectively to perform the stated function. Additionally, “set” means one or more items, and “subset” means less than the entire set, but not empty.

[0331] As used herein, unless otherwise expressly indicated, “based on” is intended to be interpreted in an inclusive sense. For example, unless otherwise explicitly indicated, “based on” may be used interchangeably with “at least partially based on,” “associated with,” “associated with,” or “according to.” Specifically, unless the phrase in the context means “based on only one” or an equivalent, whether it is “based on one” or “at least partially based on one”, it may be based solely on “one” or based on a combination of “one” and one or more other factors, conditions, or information.

[0332] The various exemplary components, logic units, logic blocks, modules, circuits, operations, and algorithmic processes described in conjunction with the examples disclosed herein can be implemented as electronic hardware, firmware, software, or a combination of hardware, firmware, or software, including the structures disclosed in this specification and their structural equivalents. This interchangeability of hardware, firmware, and software has been generally described in terms of its functionality and exemplified in the various exemplary components, blocks, modules, circuits, and processes described above. Whether this functionality is implemented in hardware, firmware, or software depends on the specific application and the design constraints imposed on the overall system.

[0333] Various modifications to the examples described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other examples without departing from the spirit or scope of this disclosure. Therefore, the claims are not intended to be limited to the examples shown herein, but are to be granted the widest scope consistent with this disclosure, the principles disclosed herein, and the novel features.

[0334] Additionally, the various features described in this specification in the context of individual examples may also be implemented in combination in a single specific embodiment. Conversely, the various features described in the context of a single specific embodiment may also be implemented individually or in any suitable sub-combination in multiple examples. Thus, although features may be described above as functioning in a particular combination, and even initially claimed in this way, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may involve sub-combinations or variations of sub-combinations.

[0335] Various aspects of this disclosure are described more fully below with reference to the accompanying drawings. However, this disclosure may be embodied in many different forms and should not be construed as limited to any particular structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be comprehensive and complete, and will fully convey the scope of protection of this disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art should understand that the scope of this disclosure is intended to cover any aspect of the disclosure herein, whether implemented independently or in combination with any other aspect of this disclosure. For example, any number of aspects set forth herein may be used to implement an apparatus or method of practice. Furthermore, the scope of this disclosure is intended to cover such apparatuses or methods implemented using structures, functions, or structures and functions other than or different from the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure herein may be embodied by one or more elements of the claims.

[0336] Similarly, although operations are depicted in a specific order in the diagrams, this should not be construed as requiring such operations to be performed in the specific order shown or in sequential order, or to perform all illustrated operations to achieve the desired result. Furthermore, the accompanying figures may schematically depict one or more example processes in the form of flowcharts or flow diagrams. However, other operations not depicted may be incorporated into the schematically illustrated example processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the illustrated operations. In some environments, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the examples described above should not be construed as requiring such separation in all examples, but rather should be understood as meaning that the described program components and systems can generally be integrated together in a single software product or encapsulated in multiple software products.

Claims

1. An apparatus for wireless communication, the apparatus comprising: A processing system, comprising processor circuitry and memory circuitry for storing code, is configured to cause the device to: Obtain multiple samples associated with multiple groupings of data; One or more transmission service patterns associated with the plurality of packets are detected, at least in part, based on one or more parameters associated with the plurality of samples, one or more parameters associated with the plurality of previous samples, or both. The plurality of packets are classified according to one or more service types, at least in part, based on the one or more transmission service modes; as well as Communicate according to one or more of the aforementioned service types.

2. The apparatus of claim 1, wherein, in order to communicate according to the one or more service types, the processing system is configured to cause the apparatus to: Output scheduling information associated with the plurality of packets, wherein the scheduling information is output based at least in part on a channel access scheme based on the one or more service types.

3. The apparatus of claim 2, wherein the processing system is further configured to cause the apparatus to: Obtain one or more channel access triggers associated with one or more channel access schemes, wherein the one or more channel access schemes include at least one of the following: The acquisition of the one or more channel access triggers is based at least in part on at least one of the one or more service types or compliance with a policy; or The output of the scheduling information is further triggered, at least in part, based on access to one or more of the channels.

4. The apparatus of claim 2, wherein the processing system is further configured to cause the apparatus to: The output is associated with one or more channel access triggers, the one or more channel access schemes including the channel access scheme, and the output is at least partially based on the one or more service types, wherein the output of the scheduling information is further at least partially based on the one or more channel access triggers.

5. The apparatus of claim 1, wherein the processing system is further configured to cause the apparatus to: Create a model to detect one or more of the aforementioned sending service patterns; The model is trained based at least in part on stream classification service requests; Detect whether one or more portions of the plurality of samples correspond to one or more transmission service types; The plurality of samples are labeled as a plurality of training samples for training the model, or a first portion of the plurality of samples is labeled as the plurality of training samples, wherein the first portion is not detected as corresponding to a corresponding transmission service type, wherein labeling the first portion is at least in part based on a second portion of the plurality of samples corresponding to a transmission service type associated with the first portion; as well as The model is trained using the plurality of training samples by labeling the plurality of samples as the plurality of training samples or by labeling the first portion of the plurality of samples as the plurality of training samples.

6. The apparatus of claim 1, wherein, in order to detect the one or more transmission service modes, the processing system is further configured to cause the apparatus to: Detect real-time services associated with a first window of the plurality of samples or streaming services associated with a second window of the plurality of samples that is longer than the first window.

7. The apparatus of claim 1, wherein, in order to classify the plurality of groups, the processing system is further configured to cause the apparatus to: The multiple packets are reclassified at least in part based on a confidence level for the type of service being sent that is less than or equal to a threshold confidence level.

8. The apparatus of claim 1, wherein, in order to detect the one or more transmission service modes, the processing system is further configured to cause the apparatus to: Output one or more parameters associated with the plurality of samples to an artificial intelligence model or machine learning model, wherein the one or more parameters include one or more service quality requirements; and The one or more sending service modes are obtained from the artificial intelligence model or machine learning model.

9. The apparatus of claim 1, wherein the processing system is further configured to cause the apparatus to: Obtain service pattern information associated with one or more other access points, wherein the detection of the one or more transmission service patterns is further based at least in part on the service pattern information; and It conveys an indication of one or more detected transmission service patterns.

10. The apparatus of claim 1, wherein the processing system is further configured to cause the apparatus to: One or more service activities, one or more service loads, or any combination thereof, are obtained at least in part based on the one or more transmission service modes, wherein each of the one or more service types, the one or more service activities, and the one or more service loads is associated with a corresponding service flow in a plurality of service flows, wherein the plurality of service flows are associated with the plurality of samples, wherein: The communication includes performing power-saving operations based on the one or more service types, the one or more service activities, the one or more service loads, or any combination thereof.

11. The apparatus of claim 10, wherein the processing system is further configured to cause the apparatus to: To acquire one or more second business types, one or more second business activities, one or more second business loads, or any combination thereof; and The second power saving operation is performed based on the one or more second service types, the one or more second service activities, the one or more second service loads, or any combination thereof.

12. The apparatus of claim 10, wherein, in order to perform the power-saving operation, the processing system is further configured to cause the apparatus to: The power-saving operation is performed based on the fulfillment of one or more conditions, wherein the one or more conditions include at least one of the following: There is a video streaming service type; There are no latency-sensitive or real-time service types; or The sum of one or more second service loads associated with a back-end service type is less than or equal to a threshold service load, wherein the one or more service loads include at least the one or more second service loads.

13. A method for conducting wireless communication at a wireless node, the method comprising: Obtain multiple samples associated with multiple groupings of data; One or more transmission service patterns associated with the plurality of packets are detected, at least in part, based on one or more parameters associated with the plurality of samples, one or more parameters associated with the plurality of previous samples, or both. The plurality of packets are classified according to one or more service types, at least in part, based on the one or more transmission service modes; as well as Communicate according to one or more of the aforementioned service types.

14. The method of claim 13, wherein communicating according to the one or more service types comprises: Output scheduling information associated with the plurality of packets, wherein the scheduling information is output based at least in part on a channel access scheme based on the one or more service types.

15. The method of claim 13, wherein detecting the one or more transmission service modes comprises: Detect real-time services associated with a first window of the plurality of samples or streaming services associated with a second window of the plurality of samples that is longer than the first window.

16. The method according to claim 13, further comprising: One or more service activities, one or more service loads, or any combination thereof, are obtained at least in part based on the one or more transmission service modes, wherein each of the one or more service types, the one or more service activities, and the one or more service loads is associated with a corresponding service flow in a plurality of service flows, wherein the plurality of service flows are associated with the plurality of samples, wherein: The communication includes performing power-saving operations based on the one or more service types, the one or more service activities, the one or more service loads, or any combination thereof.

17. The method according to claim 16, further comprising: To acquire one or more second business types, one or more second business activities, one or more second business loads, or any combination thereof; as well as The second power saving operation is performed based on the one or more second service types, the one or more second service activities, the one or more second service loads, or any combination thereof.

18. A wireless node for wireless communication, the wireless node comprising: At least one transceiver; and A processing system, comprising processor circuitry and memory circuitry for storing code, is configured to cause the wireless node to: Receive multiple samples associated with multiple packets including data via the at least one transceiver; One or more transmission service patterns associated with the plurality of packets are detected, at least in part, based on one or more parameters associated with the plurality of samples, one or more parameters associated with the plurality of previous samples, or both. The plurality of packets are classified according to one or more service types, at least in part, based on the one or more transmission service modes; as well as Communicate according to one or more of the aforementioned service types.

19. The wireless node of claim 18, wherein, in order to communicate according to the one or more service types, the processing system is configured to cause the wireless node to: Scheduling information associated with the plurality of packets is transmitted via the at least one transceiver, wherein the scheduling information is transmitted according to a channel access scheme based at least in part on the one or more service types.

20. The wireless node of claim 18, wherein the processing system is further configured to cause the wireless node to: At least in part, one or more service activities, one or more service loads, or any combination thereof are received via the at least one transceiver based on the one or more transmission service modes, wherein each of the one or more service types, the one or more service activities, and the one or more service loads is associated with a corresponding service flow in a plurality of service flows, wherein the plurality of service flows are associated with the plurality of samples, wherein: The communication includes performing power-saving operations based on the one or more service types, the one or more service activities, the one or more service loads, or any combination thereof.

Images